Weekly Web3 Security Incident Roundup | Mar 16 – Mar 22, 2026

During the past week (2026/03/16 - 2026/03/22), BlockSec detected and analyzed seven attack incidents, with total estimated losses of ~$82.7M. The table below summarizes these incidents, and detailed analyses for each case are provided in the following subsections.

1. Venus Incident

Brief Summary

On March 15, 2026, Venus Protocol's THE (Thena) market on BNB Chain suffered a donation attack combined with market manipulation, resulting in approximately ~$2.15M in bad debt. The THE market's supply cap only applied to the mint path, while direct token donations into the market still increased cash and inflated the exchangeRate. The attacker then leveraged this inflated collateral value to borrow liquid assets, acquire more THE while driving THE token's market price, ultimately leaving the protocol with bad debt after the position's forced liquidation.

Background

Venus is a Compound V2 fork lending protocol. In THE market, users deposit THE and receive vTHE tokens. The exchangeRate determines how much of the market's underlying assets each vTHE represents, and its core formula is:

exchangeRate = (cash + borrows - reserves) / totalSupply

Here, cash is the market's underlying token balance, borrows is total outstanding debt, reserves is protocol-owned reserves, and totalSupply is total vTHE supply. THE market also has a supply cap intended to limit total collateral exposure.

Vulnerability Analysis

This incident involved two compounding vectors against the vTHE market contract (0x86e0...739f).

Donation Attack

The protocol derives cash directly from the market contract's raw token balance, making it inherently susceptible to donation attacks. Any direct transfer of THE into the vTHE market contract increases cash and therefore the exchangeRate. The attacker exploited this to inflate the exchangeRate approximately 3.81×, amplifying the collateral value of their existing vTHE position.

Market Manipulation

THE token had shallow on-chain liquidity, making its spot price susceptible to manipulation through relatively modest buy pressure. The protocol's Oracle is designed to reject prices that deviate too far from a reference, which correctly rejected extreme prices for roughly 37 minutes during the attack. However, sustained buy pressure eventually pushed THE token's price to approximately $0.51, roughly double its pre-attack price, which the oracle ultimately accepted.

These two vectors reinforced each other. The inflated exchangeRate from the donation attack amplified the collateral value of each vTHE unit, while the manipulated THE token price further inflated the borrow capacity. Together, they allowed the attacker to accumulate ~$14.9M in borrows against a position that was 3.67× the supply cap.

Attack Analysis

The following analysis is based on the example attack transaction 0xce6e3e...1f5fb0e.

• Step 1: A wallet linked to the attacker received 7,447 ETH through 77 TornadoCash-related transactions over roughly nine months. That ETH was deposited into Aave and ~$9.92M in stablecoins was borrowed to build a vTHE position of about 12.2M THE, roughly 84% of the 14.5M THE supply cap.

• Step 2: In the first attack transaction, six addresses transferred about 36M THE directly into vTHE market contract. The attack contract also borrowed 1.58M USDC, re-supplied it, then borrowed about 4.6M THE and transferred it directly into vTHE. This lifted the exchangeRate by about 3.81x.

• Step 3: In the subsequent transactions, the attacker borrowed liquid assets, including CAKE, BNB, BTCB, and USDC. The attacker kept buying THE with borrowed assets and donating more THE into vTHE, creating a loop that increased both position borrowing power and THE token's market price.

• Step 4: THE token's price rose from about $0.2, with the Binance price source briefly approaching $4. The protocol's oracle rejected extreme prices for roughly 37 minutes before ultimately accepting a price of about $0.51.

• Step 5: By 20:42 UTC+8, the attacker's position reached about 53.2M THE, roughly 3.67x the supply cap, with total borrow exposure of about ~$14.9M.

• Step 6: The position then entered large liquidations. About 42M THE collateral was liquidated across 8,048 liquidation transactions from 254 liquidator addresses. As selling continued, THE token fell to about $0.22. Liquidation proceeds could not cover the full debt, leaving Venus with ~$2.15M in net bad debt.

Conclusion

This incident revealed no novel vulnerability. It demonstrated how a well-known attack vector, executed methodically, can overwhelm a protocol's entire risk stack when each layer assumes the others will hold. Warning signals had been visible on-chain for months, yet the gap between detection and intervention went unaddressed. Bridging that gap through liquidity-aware risk parameters, automated circuit breakers, and position-level monitoring is the central lesson this incident leaves for other lending protocols.

For a detailed analysis, see our deep-dive post [1].

References

• [1] https://blocksec.com/blog/venus-thena-donation-attack

2. dTRINITY Incident

Brief Summary

On March 17, 2026, dTRINITY, an Aave V3 fork lending protocol on Ethereum, was exploited through its dLEND lending market, resulting in a loss of ~$257.3K. The root cause was the empty market vulnerability inherent to Aave V3 forks. When a reserve holds near-zero liquidity, repeated flash-loan premium accrual drives liquidityIndex to an extreme value. Once the reserve accounting was distorted, the attacker exploited the precision loss in the deposit and withdrawal paths to overstate collateral, borrow dUSD, and recover the deposited cbBTC for a net profit.

Background

dTRINITY includes the dUSD stablecoin system and dLEND, a lending market forked from Aave V3. In the core L2Pool contract (0xfda3...e19e84), each asset has its own reserve, and reserve accounting is based on scaled balances and a reserve level liquidityIndex. A user's current underlying balance is derived from the scaled balance multiplied by the reserve's normalized income.

Flash loan premiums are added to reserve accounting through cumulateToLiquidityIndex(), where:

nextLiquidityIndex = ((amount / totalLiquidity) + 1) * reserve.liquidityIndex

When totalLiquidity becomes extremely small, each premium accrual can push the liquidityIndex upward at an abnormally fast rate.

Vulnerability Analysis

The key condition for the attack was a near empty reserve in the dLEND-cbBTC market (0x504d...3acc). Once the reserve was compressed to a single scaled share, flash loan premiums were no longer spread across a meaningful supply base. Repeated flash loans therefore caused the liquidityIndex to rise extremely quickly.

After the liquidityIndex was inflated, the underlying to scaled conversion entered an extreme rounding regime. In this state, a small deposit could mint one additional share, while a much larger withdrawal could still burn only one share. This asymmetry allowed the attacker to overstate aCbBTC collateral and borrow real dUSD from a different reserve, because health checks were performed at the Pool level and the corrupted cbBTC reserve directly affected cross-asset borrowing power.

Attack Analysis

The exploit consisted of two transactions: 0x8d33d6...40ae7139 and 0xbec4c8...4fc33260.

Transaction 1: liquidityIndex manipulation

• Step 1: Borrow cbBTC from Morpho Blue.

• Step 2: Deposit cbBTC into dLEND-cbBTC to mint 100 scaled shares.

• Step 3: Withdraw 99 units of shares so that only 1 share remains, compressing the dLEND-cbBTC reserve into an almost-empty scaled-supply state.

• Step 4: Transfer 80,000,000 units of cbBTC (i.e., 0.8 cbBTC) directly to the dLEND-cbBTC aToken.

• Step 5: Execute 150 Pool.flashLoan() calls to accumulate premium into reserve accounting, raising liquidityIndex to 6,226,621,999,999,999,999,999,999,979,728,276.

• Step 6: Run repeated deposit and withdraw cycles to extract residual reserve cash.

• Step 7: Repay flashloan.

Transaction 2: profit realization

• Step 1: Borrow cbBTC again from Morpho Blue.

• Step 2: Deposit ~7.72 cbBTC into the already-manipulated reserve to build an overstated aCbBTC collateral position.

• Step 3: Use the overstated collateral to borrow 257,328 dUSD from the dLEND-dUSD market.

• Step 4: Continue cbBTC extraction through repeated deposit/withdraw cycles.

• Step 5: Repay Morpho flashloan, and transfer borrowed dUSD to the attacker EOA.

Conclusion

This incident is an instance of the empty market attack that has been well-documented across Aave V3 forks. This pattern has appeared in multiple protocols, and the mitigation is well established. Enforcing a minimum supply threshold during reserve initialization prevents the reserve from entering a state where index growth becomes uncontrollable. Protocols that fork Aave V3 should therefore treat reserve bootstrapping as a critical operation and ensure meaningful liquidity is locked at deployment, rather than relying on organic deposit flow to stabilize the index.

3. Fun.xyz Incident

Brief Summary

On March 17, 2026, Fun.xyz, a checkout infrastructure protocol on Polygon, was exploited for ~$85.7K. The root cause was that the legacy CheckoutPool exposed a critical function bridge() without access control and without binding bridge calldata to the intended recipient. This vulnerability allowed the attacker to redirect execution into the trusted settlement path and transfer funds to an attacker-controlled smart account.

Background

CheckoutPool is the core settlement contract in Fun.xyz's checkout infrastructure. In the normal flow, a user creates a checkout via deposit(), and a trusted operator advances it through settlement paths such as bridge() and execute(). For bridge operations, bridge() executes an external call based on caller-supplied bridgeParams.target and bridgeParams.callData.

Vulnerability Analysis

The root cause is that the legacy CheckoutPool (0x1304...2ec01a) exposed a sensitive settlement-routing path through function bridge() without proper access control, while also failing to validate the externally supplied bridge calldata against the intended recipient. Specifically:

• The legacy implementation did not enforce onlyOperator on bridge(), allowing any external caller to invoke the function after creating a checkout via deposit().

• bridge() passed caller-supplied bridgeParams into _bridgeToRecipient(), which performed an external call without validating the recipient against the checkout record.

An additional operational condition made the exploit practical: the legacy CheckoutPool still retained operator privileges in CheckoutPaymaster at the time of the exploit. This allowed the crafted bridge() call to reach CheckoutPaymaster.activateAndCall(), which then invoked the newer CheckoutPool.execute() path, transferring funds to an address under attacker control.

Attack Analysis

The following analysis is based on the attack transaction 0x957bcf...1f4f5a.

• Step 1: Create the ERC-4337 smart account 0xb648 and designate it as both the sender and the paymaster in the external UserOperation.

• Step 2: Call deposit() in both the legacy and the new CheckoutPool, creating a checkout record in the new CheckoutPool with a settlement amount of 85,730 USDC.

• Step 3: Call bridge() in the legacy CheckoutPool with malicious bridgeParams: set bridgeParams.target to CheckoutPaymaster, and encode bridgeParams.callData as a call to activateAndCall() carrying the external UserOperation as its internal payload.

• Step 4: Reach execute() in the new CheckoutPool (0x1929...0215), which transfers 85,730 USDC to 0xb648, the address specified as ops[0].sender in the external UserOperation.

• Step 5: Enter EntryPoint.handleOps(): because 0xb648 serves as both the sender and the paymaster, both account validation and paymaster validation remain under attacker control, allowing the attacker to profit 85,730 USDC.

Conclusion

This incident was caused by the legacy CheckoutPool lacking both access control and calldata-to-recipient binding on its bridge() path, resulting in losses of ~$85.7K. To prevent similar incidents, protocols should enforce strict access control across sensitive routing and settlement flows, ensure externally supplied payloads remain consistent with protocol-derived recipients, and remove stale contracts from trusted privilege relationships once patched replacements are deployed.

4. Keom Incident

Brief Summary

On March 18, 2026, Keom, a Compound V2 fork lending protocol on Polygon zkEVM, was exploited for approximately $35K. The root cause was flawed accounting logic in redeemFresh(), called by redeemUnderlying(). The function capped the share reduction to the user's actual balance but did not recompute the underlying withdrawal amount accordingly. This mismatch allowed the attacker to redeem far more assets than their shares should permit.

Background

Keom is a lending protocol forked from Compound V2. Users supply ETH to the market and receive kETH. When a user redeems, the protocol converts kETH shares back into ETH using the current exchange rate. Two redemption entry points exist in the protocol: redeem() for redeeming by share amount, and redeemUnderlying() for redeeming by the desired underlying amount.

Vulnerability Analysis

The flaw is in redeemFresh() of the kETH market (0x4c6e...0403), called by redeemUnderlying(). The user-controlled redeemAmountIn is first assigned to redeemAmount, and then used to compute redeemTokens via the current exchange rate. If redeemTokens exceeds the redeemer's balance, the function caps it to accountTokens[redeemer]. However, redeemAmount is not recomputed after this cap and remains equal to the original redeemAmountIn. This allows the redeemer to withdraw the full redeemAmount of underlying assets while only burning a fraction of the corresponding shares.

As shown in the code snippet below, redeemFresh() also performs a health check via redeemAllowed(). In the Compound V2 design, redeemAllowed() checks markets[cToken].accountMembership[redeemer] and only invokes the liquidity check when the account has entered this cToken market; otherwise, the check is skipped entirely. Because redeemAmountIn is attacker-controlled and can be set arbitrarily large, the liquidity check would fail if kETH still counts as collateral. This means the accounting flaw alone is not directly exploitable without first bypassing the health check.

Attack Analysis

The following analysis is based on the attack transaction 0x4ccde7...03d9dfd8.

• Step 1: Invoke mint() with only 0.001 ETH, obtaining a minimal kETH balance.

• Step 2: Invoke exitMarket() to clear the account's membership in the kETH market, so that redeemAllowed() bypasses the liquidity check entirely (as described in the Vulnerability Analysis above).

• Step 3: Invoke redeemUnderlying() to withdraw the market's entire ETH balance (~38.6 ETH), exploiting the flawed accounting to drain ETH from the market.

Conclusion

This incident was caused by an accounting vulnerability that fails to recompute redeemAmount after capping redeemTokens to the user's actual balance, resulting in approximately $35K in losses. Redemption logic must recompute all dependent values after any cap or adjustment to preserve the share-to-underlying invariant. Compound V2 forks should review this path carefully, as similar flaws may exist in other derivatives.

5. ShiMama Incident

Brief Summary

On March 18, 2026, ShiMama, a deflationary token protocol on BNB Chain, was exploited for approximately $35K. The root cause was a lack of access control on function executePairBurn(), which allowed any user to trigger pair reserve withdrawal and burn, enabling price manipulation.

Background

ShiMama Protocol includes an on-chain deflation mechanism intended to pull tokens from the AMM pair and burn them. This mechanism is implemented across ShiMama Protocol and ShiMama Token. The function executePairBurn() in ShiMama Protocol computes a pull amount from a caller-supplied referenceIn parameter:

pullAmt = referenceIn * pairBurnBpOnSell / 10_000

It then calls ShiMama Token's forcePullFromPair() followed by pair.sync() and a burn of the pulled tokens.

Vulnerability Analysis

The root cause is a lack of access control on executePairBurn() in the ShiMamaProtocol contract (0x5049...0b49a). The function is externally callable without restriction, so any user can trigger privileged reserve movement and pair sync. referenceIn is also caller-controlled and not bound to any real sell amount. In ShiMamaToken.forcePullFromPair(), the protocol can directly move balances from the Pancake pair without any constraint, enabling arbitrary reserve removal plus immediate sync and therefore spot-price manipulation.

Attack Analysis

The following analysis is based on the attack transaction 0x13959b...3c20e001.

• Step 1: Borrow WBNB from Moolah flashLoan.

• Step 2: Transfer 30.78e18 ShiMama pre-sourced in an earlier transaction into the attack contract. Since direct ShiMama buys from the Pancake pair were disabled, the attacker sourced ShiMama by providing and withdrawing liquidity in ShiMama Protocol prior to the attack.

• Step 3: Call executePairBurn() to pull 1,311,349,143.96 ShiMama tokens from the Pancake pair and burn them, effectively inflating the ShiMama price.

• Step 4: The attacker swapped 30.78e18 ShiMama for 52.98e18 WBNB on PancakeSwap at the inflated price.

• Step 5: Repay the flash loan, leaving 52.98 WBNB as net profit.

Conclusion

This incident was caused by a lack of access control on executePairBurn(), which exposed an unauthorized pathway to alter pool reserves. Any reserve-mutating function is economically sensitive and must be strictly permissioned. Caller-controlled inputs must be bound to protocol-derived values to prevent reserve extraction amplification.

6. BlindBox Incident

Brief Summary

On March 19, 2026, BlindBox, a GameFi betting protocol on BNB Chain, was exploited for approximately $99K. The root cause was weak randomness, allowing the attacker to predict the outcome and achieve a 100% win rate. In addition, getTwapPrice() relied on manipulable spot pricing rather than a true time-weighted average, allowing the attacker to inflate the pool price beforehand and place bets larger than the protocol's intended limits.

Background

The BlindBox is a GameFi protocol that allows users to place bets by transferring ATM tokens to the dead address. The protocol determines the outcome based on the parity of a later blockhash. If the bet wins, BlindBox pays out 1.95x the original ATM amount from the dead-address bankroll. The protocol uses getTwapPrice() to limit the size of each bet.

Vulnerability Analysis

The BlindBox contract (0x1F83...734c59) contains two vulnerabilities:

1. Weak randomness: When the settlement time exceeds 256 blocks, blockhash(bet.blockNum + 2) returns zero. The protocol then falls back to randomness derived from block.prevrandao, betId, and block.timestamp. Since these inputs can be simulated off-chain before submitting the transaction, the attacker could invoke settle() only when the computed result was favorable, achieving a deterministic win.

2. Manipulable price limit: The protocol uses getTwapPrice() to constrain bet size. However, this function does not implement a true time-weighted average price; it instead reads the spot price in the ATM/USDT pool. This allows attackers to bypass the limit by manipulating the pool price before placing their bet.

Attack Analysis

The following steps illustrate the attack pattern. Steps 2 and 3 formed a paired sequence (e.g., betId=5,284), and the attacker repeated this pair multiple times to accumulate profit.

• Step 1: Manipulate the ATM/USDT pool, inflating the ATM spot price so that getTwapPrice() would permit a larger bet size in the next step.

• Step 2: Place a large bet by transferring the inflated-allowance ATM amount to the dead address (e.g., 0x4be049...3af12c).

• Step 3: Wait until more than 256 blocks had passed, so blockhash returned zero and the fallback path activated. The attacker then simulated outcomes off-chain and called settle() only at a block where the computed result was favorable (e.g., 0x68eedc...718ce8).

Conclusion

This incident was caused by predictable randomness, combined with a manipulable spot price as a TWAP input, resulting in approximately $99K in losses. To reduce similar risks, the protocol should remove any settlement path that becomes predictable after the blockhash window expires, and replace getTwapPrice() with a pricing source resistant to short-term reserve manipulation.

7. Resolv Incident

Brief Summary

On March 22, 2026, Resolv, a stablecoin protocol on Ethereum, experienced an infrastructure-key compromise that enabled unauthorized execution of privileged swap-finalization logic. In the incident, the attacker abused the privileged function to mint over 80M uncollateralized USR. The impact extended beyond the direct minting event, as the resulting USR depeg triggered broader contagion across lending protocols where Resolv assets were used as collateral.

Background

Resolv is a stablecoin protocol in which USR issuance depends on collateral-backed swap settlement. Its swap completion pipeline, completeSwap() -> mint() -> transfer(), directly affects the circulating supply of USR and therefore depends on both authorization integrity and collateral integrity. Under normal operation, completeSwap() in the Resolv contract (0xa27a...5861) is callable only by a privileged infrastructure key (named SERVER_ROLE in code) after the corresponding collateral deposit has been verified.

Vulnerability Analysis

The incident was a compromised privileged key that invoked trusted settlement logic and reached the USR mint path without an equivalent collateral inflow. Once the attacker obtained control of the privileged signing authority, the completeSwap() path provided no on-chain mint precondition enforcement; collateral verification was entirely dependent on off-chain authorization. This converted a control-plane compromise directly into a supply-integrity failure.

Attack Analysis

• Step 1: Prior to the exploit, the attacker submitted a swap request in transaction 0x590b5c...de732c89, preparing the necessary state for subsequent malicious swap completion.

• Step 2: Using the compromised privileged key, the attacker invoked completeSwap() to mint over 80,000,000 USR across three transactions: 0xfe37f2...dc33743, 0x41b6b9...db1f18f, and 0x7f9143...53a931d.

Conclusion

This incident underscores that stablecoin safety depends on hard on-chain mint preconditions, not only trusted operator roles. Notably, the impact of this incident extended far beyond the $80M in unauthorized USR minting. Because Resolv assets were widely used as collateral across multiple lending protocols, the depeg set off broader contagion. As reported by Chaos Labs, on-chain curators using automated yield-seeking allocation lacked real-time risk controls and continued directing fresh capital into already impaired markets. What began as a localized exploit quickly escalated into a cross-protocol contagion event, leaving lending protocols with millions in bad debt.

About BlockSec

BlockSec is a full-stack blockchain security and crypto compliance provider. We build products and services that help customers to perform code audit (including smart contracts, blockchain and wallets), intercept attacks in real time, analyze incidents, trace illicit funds, and meet AML/CFT obligations, across the full lifecycle of protocols and platforms.

BlockSec has published multiple blockchain security papers in prestigious conferences, reported several zero-day attacks of DeFi applications, blocked multiple hacks to rescue more than 20 million dollars, and secured billions of cryptocurrencies.

• Official website: https://blocksec.com/

• Official Twitter account: https://twitter.com/BlockSecTeam

• 🔗 BlockSec Auditing Service : Submit a request

• 🔗 Phalcon Security APP: Book a demo

• 🔗 Phalcon Compliance