KelpDAO, dTrinity, and DBXen Exploits: $290M+ Lost to Validator Compromise, Flash Loan Manipulation, and msg.sender Flaws

In Brief

• KelpDAO lost $290M due to compromised validators.
• dTRINITY lost $257K after flash loan fee manipulation inflated the liquidity index.
• DBXen lost $149K due to a msg.sender/_msgSender() inconsistency.

Hacks Analysis

KelpDAO | Amount Lost: $290M

On April 18th, the KelpDAO exploit on Ethereum mainnet resulted in a $290M loss. The root cause of the exploit was the compromise of validators and the lack of multiple validators to approve cross-chain messages (LayerZero Labs was sole verifier). After compromising two validators, the attacker was able to mint ~116,500 rsETH without any collateral. The exploit impacted multiple protocols that accepted rsETH as collateral.

Transaction: 0x1ae232da212c45f35c1525f851e4c41d529bf18af862d9ce9fd40bf709db4222

dTRINITY | Amount Lost: $257K

On March 17th, the dTRINITY dLEND exploit on Ethereum mainnet resulted in a $257K loss. The root cause of the exploit was a flaw in how the protocol calculated collateral value when very few tokens were supplied to the cbBTC market. The protocol used a liquidity index to track earned fees and determine collateral value. Because the total supply was extremely small, the attacker was able to increase the index by repeatedly taking and repaying flash loans to generate fees. This made the attacker’s position appear more valuable than it actually was. The attacker first reduced the supply and became the only supplier, then inflated the index through flash loans, and finally borrowed 257,328 dUSD against the inflated value and made a profit.

Exploited Contract: 0x504d0eacbf9ea5645a8a9da1b15f3708a5483acc

Transaction: 0x8d33d688def03551cb77b0463f55ae5a670f5ebf3bbb5b8aa0e284c040ae7139

DBXen | Amount Lost: $149K

On March 11th, the DBXen exploit on Ethereum mainnet resulted in a $149K loss. The root cause of the exploit was an inadvertent mixing of msg.sender and _msgSender() when claiming rewards. The protocol lets users burn XEN tokens in cycles to earn DBXen rewards, tracked through accCycleBatchesBurned and lastActiveCycle. In burnBatch(), burned batches were credited to the user via _msgSender(). However, lastActiveCycle was updated using msg.sender, which pointed to the forwarder. This left the attacker’s lastActiveCycle unchanged. When calling claimRewards(), the contract treated the rewards as unclaimed. The attacker was able to repeatedly claim rewards from a single burn and make a profit.

Exploited Contract: 0xf5c80c305803280b587f8cabbccdc4d9bf522abd

Transaction: 0x914a5af790e55b8ea140a79da931fc037cb4c4457704d184ad21f54fb808bc37