Weekly Web3 Security Incident Roundup | Mar 23 – Mar 29, 2026

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

Date	Incident	Type	Estimated Loss
2026/03/23	Unknown Incident 1	Integer overflow	~$97K
2026/03/23	Unknown Incident 2	Reentrancy	~$11K
2026/03/23	Cyrus Finance Incident	Business logic flaw	~$512K
2026/03/23	BCE Token Incident	Token design flaw	~$679K
2026/03/25	Unknown Incident 3	Accounting error	~$1.2K
2026/03/25	MYX Incident	Business logic flaw	~$3.6K
2026/03/26	Unknown Incident 4	Token design flaw	~$133.5K
2026/03/27	EST Token Incident	Token design flaw & Spot price dependency	~$92.3K

1. Unknown Incident 1

Brief Summary

On March 23, 2026, an unverified contract on Ethereum was exploited for approximately $97K due to an integer overflow in its distribution logic. The function 0x317de4f6() summed user-controlled token amounts without overflow protection, allowing the attacker to trigger a wraparound and withdraw the contract's full USDT balance via the claim() function by paying only 1 wei USDT.

Vulnerability Analysis

The root cause was an integer overflow in the function 0x317de4f6() of the contract 0xF0a105...568C97. The function accepts an array of records (each with an account and an amount) and sums all amounts into totalAmount by iterating the array. Because the accumulation lacked overflow checks, an attacker could supply crafted records whose amounts wrap around uint256, making totalAmount arbitrarily small while the individual allocations remain large.

Attack Analysis

The following analysis is based on the transaction 0x73bd1384...630b053.

Step 1: The attacker took 1 wei of USDT from Uniswap V4 as the initial capital for the attack.
Step 2: The attacker queried the victim contract's USDT balance and then invoked 0x317de4f6() with a crafted array. One amount was set near the uint256 upper bound, and the other was set to the victim contract's USDT balance. Their sum overflowed to 1, allowing the attacker to pay only 1 wei USDT while recording an allocation equal to the victim's full USDT balance.
Step 3: The attacker invoked claim() to withdraw 97,812e6 USDT from the victim contract.
Step 4: The attacker repaid the 1 wei USDT borrowed from Uniswap V4 and swapped the remaining USDT for WETH, completing the exploit.

Conclusion

This incident highlights the risks of using unchecked arithmetic in Solidity versions prior to 0.8.0. All critical financial calculations should explicitly use overflow-safe arithmetic (e.g., SafeMath or Solidity >=0.8.x) to prevent wraparound issues.

2. Unknown Incident 2

Brief Summary

On March 23, 2026, an unverified contract on Ethereum was exploited for approximately $11K due to a reentrancy vulnerability. The function 0xbe16634e() updated liquidity-related accounting before settlement and invoked an external callback without any reentrancy protection. By reentering the function repeatedly before the previous call settled, the attacker inflated their recorded liquidity and later withdrew more USDC and WETH than they had actually deposited.

Vulnerability Analysis

The root cause is a reentrancy issue in the function 0xbe16634e() of the contract 0x39Ed37...9C6b08. This function updates liquidity-related state, including user liquidity and tick reserves, before settlement and invokes an external callback via msg.sender.call() without any reentrancy guard. Because the balance check is performed on a per-call basis, the attacker can recursively reenter the function and inflate internal liquidity accounting, while a single token transfer in the deepest call is enough to satisfy the nested execution flow.

Attack Analysis

The following analysis is based on the transaction 0x1382e898...fad993.

Step 1: The attacker took 100e8 USDC and 10e18 WETH from Uniswap V4 as the initial capital for the attack.
Step 2: The attacker invoked 0xbe16634e() to add liquidity. During execution, the victim contract called the attacker's function 0x7c65be42(), which reentered 0xbe16634e() before the previous call settled.
Step 3: By repeating this reentrant flow multiple times, the attacker continuously increased their recorded liquidity. In the deepest call, the attacker transferred the required tokens once, which was sufficient to satisfy the nested balance checks.
Step 4: After inflating the recorded liquidity, the attacker checked the pool state and transferred additional funds into the pool so that it held enough USDC and WETH to cover the upcoming withdrawal.
Step 5: The attacker invoked 0xbe16634e() again to remove liquidity and withdrew USDC and WETH from the pool based on the inflated accounting.
Step 6: The attacker repaid Uniswap V4, swapped the remaining USDC for WETH, and completed the exploit.

Conclusion

This incident shows the danger of updating liquidity accounting before settlement while invoking an unprotected external callback. To prevent similar exploits, protocols should strictly follow the checks-effects-interactions pattern and protect external callbacks with reentrancy guards.

3. Cyrus Finance Incident

Brief Summary

On March 23, 2026, Cyrus Finance, a yield-farming protocol on BNB Chain, was exploited for approximately $512K due to a flawed liquidity removal formula that depends on the pool's current spot price. The protocol uses CYRP NFT positions to represent a proportional share of its PancakeSwap V3 liquidity, but the conversion from user share to underlying liquidity reads slot0(), which is manipulable within the same transaction. By shifting the price via a flash-loan-funded swap, the attacker inflated the liquidity value of their NFT position and withdrew more than their fair entitlement.

Background

Cyrus Finance is a yield-farming protocol on BNB Chain that manages liquidity positions in PancakeSwap V3 pools. Users deposit USDT to receive CYRP NFT positions, which represent their share of the protocol's liquidity across multiple PancakeSwap V3 positions. Users can withdraw their principal plus rewards through the exit() function.

Vulnerability Analysis

The vulnerability lies in the withdrawUSDTFromAny() function in CyrusTreasury (0xb042Ea...0aE10b). When processing a withdrawal, the function fetches sqrtPriceX96 from the PancakeSwap V3 pool's slot0() (i.e., the current spot price) and passes it into getAmountsForLiquidity() to estimate how much amount0 / amount1 the protocol's full position liquidity currently represents.

It then derives availableUSDT from that spot-price-based valuation and uses the following formula to determine how much liquidity should be removed for the requested withdrawal:

$liquidityToUse = liquidity \cdot remaining / availableUSDT$

In other words, the contract does not redeem a fixed ownership share directly. Instead, it first estimates the position's current USDT-equivalent value using the live pool price, and then converts the requested USDT amount back into a proportional liquidity amount.

This is unsafe because slot0() is manipulable within the same transaction. By temporarily moving the pool price, an attacker can distort availableUSDT, which directly affects the computed liquidityToUse.

Attack Analysis

The following analysis is based on the transaction 0x85ac5d15...46d452.

Step 1: The attacker initiated a flash loan from a PancakeSwap V3 pool, borrowing approximately 1,798 ETH.
Step 2: The attacker executed a large ETH to USDT swap in the target pool where the protocol maintained liquidity, deliberately shifting the pool price and current tick. In parallel, the attacker transferred CYRP NFT position #15505 from 0x01737d...6ffa3 to the attack contract via safeTransferFrom().
Step 3: The attacker invoked exit(15505) on CyrusTreasury. During execution, withdrawUSDTFromAny() read slot0() from the PancakeSwap V3 pool and computed availableUSDT based on the manipulated spot price. Due to the distorted tick, the protocol overestimated the liquidity value corresponding to the NFT share. It then called decreaseLiquidity() and collect(), releasing excess USDT beyond the Cyrus position's fair value.
Step 4: The attacker restored the pool state, repaid the flash loan, and transferred the remaining profit (~$512K) to EOA 0xf96EB1...3b63b.

Conclusion

Mitigation should replace spot slot0() pricing with manipulation-resistant pricing (TWAP over a sufficient observation window, or an external oracle such as Chainlink) before converting liquidity into withdrawable USDT.

4. BCE Token Incident

Brief Summary

On March 23, 2026, the PancakeSwap BCE-USDT pool on BNB Chain was exploited for approximately $679K due to a flawed burn mechanism in the BCE token. The attacker deployed two malicious contracts to bypass BCE's buy/sell limits and triggered token burns against the liquidity pool reserves, manipulating the pool's price and draining its USDT.

Vulnerability Analysis

The vulnerability originates from the BCE token's (0xcdb189...999999) flawed burn mechanism. The core issue is that a user-influenced state variable scheduledDestruction is used to burn tokens directly from the PancakeSwap pair address rather than from the user's own balance. During sell operations, the contract accumulates a destruction amount in scheduledDestruction based on the traded volume and current pool reserves. This value is not deducted from the seller. Instead, it is later executed through a separate code path that burns tokens from the pair and calls sync().

Because the attacker controls the trade volume and can manipulate pool reserves, they can set scheduledDestruction to an arbitrary value and trigger a burn that compresses the pair's BCE reserve, distorting the pool price in their favor.

Attack Analysis

The following analysis is based on the transaction 0x85ac5d15...46d452.

Step 1: The attacker invoked a malicious contract (MC1) to borrow 123.5M USDT via multiple flash loans and a lending pool.
Step 2: The attacker deployed a second malicious contract (MC2) and transferred all borrowed USDT to MC2.
Step 3: The attacker (via MC2) swapped 2.222M USDT for 5.529M BCE in the BCE-USDT pool.
Step 4: The attacker transferred 5.529M BCE from MC2 to MC1 (via MC1.drain()); due to the burn mechanism, MC1 received 2.764M BCE.
Step 5: The attacker (via MC1) swapped 2.488M BCE for 1.368M USDT, updating the variable scheduledDestruction to ~174K based on pool reserves and swap amount. The variable was later used as the burning amount.
Step 6: The attacker (via MC2) swapped 34.9M USDT for 3.484M BCE, further manipulating the BCE reserve toward ~174K.
Step 7: The attacker transferred 3.484M BCE and remaining USDT from MC2 to MC1. Since scheduledDestruction was greater than 0 (i.e., ~174K), the transfer of BCE triggered burns that compressed the BCE reserve to ~10,000.
Step 8: The attacker swapped the remaining BCE for USDT at the manipulated price.
Step 9: The attacker repaid all loans and netted approximately $679K profit.

Conclusion

This incident was caused by a fundamental flaw in the token's economic logic, where a user-influenced state variable was used to modify the balance of the liquidity pool instead of the user's own balance. The contract implicitly assumed that destruction derived from trading activity would reflect user cost, but in practice, it allowed attackers to construct a deferred burn settled against LP reserves. As a result, attackers could manipulate pool depth and pricing with limited capital exposure, extracting value from liquidity providers.

5. Unknown Incident 3

Brief Summary

On March 25, 2026, an unverified staking contract on BNB Chain was exploited for approximately $1.2K due to inconsistent accounting across multiple staking modes. The contract shared the same position variable across stake2()/withdraw2() and stake3()/withdraw3(), even though these functions handled different token baskets and ratios. The attacker deposited through the lighter stake2() mode and redeemed through the heavier withdraw3() mode, repeatedly extracting excess tokens.

Background

This is a staking contract with several stake and withdraw modes. The standard stake() and withdraw() path is the full staking mode, which handles a basket of Pangolin, Bzzt, and Bzzone together with reward-accounting logic. The stake3() and withdraw3() path uses the same three-token basket and the same deposit/withdraw ratio, but skips the additional reward-accounting flow. In contrast, the stake2() and withdraw2() path is a lighter mode that handles only Pangolin and Bzzt, and therefore uses a different token combination and ratio from the other two modes.

Vulnerability Analysis

The root cause was inconsistent accounting in the contract 0x29d36c...774137. Although stake2()/withdraw2() and stake3()/withdraw3() handled different token baskets, they all updated the same variables _exit[msg.sender] and _totalSupply. As a result, a position created through the lighter stake2() mode could be redeemed through the heavier withdraw3() mode.

In practice, stake2(amount) pulled only amount of Pangolin and amount of Bzzt, but withdraw3(amount) transferred back amount of Pangolin, 10 * amount of Bzzt, and 10 * amount of Bzzone. This meant that staking 20e18 Pangolin and 20e18 Bzzt through stake2() created an _exit balance that could later be used to withdraw 20e18 Pangolin, 200e18 Bzzt, and 200e18 Bzzone through withdraw3(). By repeating this mismatch, the attacker continuously extracted excess tokens from the contract.

Attack Analysis

The following analysis is based on the transaction 0x7fcd5882...323f8d.

Step 1: The attacker deployed a contract at 0x9bce07d8bbe4f19dfe465710ff9612878bfe3302, funded it with 0.05 BNB, wrapped the funds into WBNB, swapped for exactly 20e18 Pangolin, 20e18 Bzzt, and 200e18 Bzzone, and approved the staking contract to spend the acquired tokens.
Step 2: The attacker called stake2() with the input 20e18, which transferred 20e18 Pangolin and 20e18 Bzzt into the staking contract and increased the attacker's shared _exit balance by 20e18.
Step 3: The attacker then called withdraw3() with the input 20e18. Because withdraw3() only checked the shared _exit balance, the contract transferred back 20e18 Pangolin, 200e18 Bzzt, and 200e18 Bzzone, even though the position had been created through stake2().
Step 4: The attacker repeated the stake2() -> withdraw3() cycle many times within the same transaction. In each round, the returned Pangolin and a small portion of the returned Bzzt were reused for the next stake2() call, while Bzzone was sent back to the staking contract so that later withdraw3() calls could continue to succeed. Through this loop, the attacker increased their Bzzt balance from 20e18 to 16,400e18.
Step 5: The attacker swapped the acquired tokens back into WBNB, unwrapped the funds to BNB, and transferred approximately 2.007e18 BNB back to the attacker EOA, completing the exploit.

Conclusion

To prevent similar exploits, staking contracts should isolate accounting for each mode and ensure that every withdrawal path matches the exact asset composition and ratio of its corresponding deposit path.

6. MYX Incident

Brief Summary

On March 25, 2026, the MYX Network's sMYX contract on Ethereum was exploited, resulting in approximately 6.67 million MYX tokens drained from the pool (~$3.6K in profit). The root cause was a flawed interaction between the transfer function's supply accounting and the dividend distribution logic in the sMYX contract. By repeatedly transferring sMYX between controlled accounts, the attacker inflated the profit-per-share variable, fabricated unbacked dividends, and extracted more MYX than originally deposited.

Background

The sMYX contract (0x404328...d27F66) follows a dividend-distribution token model. Users deposit MYX tokens through a buy function and receive sMYX shares representing their stake. Dividends are tracked using a global accumulator (profit-per-share) stored in stor_11. Each user's claimable dividends are calculated as the difference between their proportional share of accumulated profit and their recorded payout baseline. This model is conceptually similar to earlier reflection-style tokens, where incoming value is redistributed among existing holders.

Vulnerability Analysis

The vulnerability arises from a flawed interaction between supply accounting and dividend distribution logic. The transfer function incorrectly introduces new dividends by increasing the global profit-per-share variable based on the transferred amount divided by the current total supply. This operation is not backed by any actual inflow of MYX tokens, meaning that dividends are effectively created from internal accounting rather than real economic activity. At the same time, the function reduces the recorded total supply by the transferred amount due to the reversed semantics of the subtraction helper, even though no tokens are actually burned.

As a consequence, each subsequent transfer results in a larger increment to the profit-per-share value, since the same transfer amount is divided by an increasingly smaller total supply.

Attack Analysis

The following analysis is based on the transaction 0x843c9ea7...a55b90.

Step 1: The attacker bootstrapped capital via a flash swap and converted it into MYX, then deposited into the sMYX contract to acquire a dominant share position within the dividend system, ensuring control over most future reward distribution.
Step 2: The attacker split their position across two controlled contracts and initiated a coordinated loop that alternated between dividend realization and state manipulation, enabling repeated traversal of the vulnerable accounting path.
Step 3: Through repeated transfers between controlled accounts, the attacker artificially inflated the protocol's profit-per-share variable while simultaneously reducing the recorded total supply, creating unbacked dividends and amplifying their distribution rate.
Step 4: By continuously withdrawing after each manipulation cycle, the attacker extracted the majority of these fabricated rewards, effectively draining MYX reserves from the protocol without introducing new capital.
Step 5: The attacker exited all positions, swapped the extracted MYX back to WETH, repaid the flash loan, and retained the remaining balance as profit.

Conclusion

This incident is not merely a consequence of a Ponzi-like economic design but rather a critical flaw in the implementation of dividend accounting. To mitigate such vulnerabilities, transfer operations must not affect total supply or trigger dividend distribution, and profit-per-share updates must only occur when real assets are introduced.

7. Unknown Incident 4

Brief Summary

On March 26, 2026, a TUR staking contract with referral rewards on BNB Chain was exploited for approximately $133.5K. The Stake contract calculated deposit value using live AMM spot prices, which are manipulable within a single transaction. The attacker used a flash loan to inflate TUR's price, staked during the inflated window, and drained outsized TUR rewards through self-controlled referrer accounts.

Background

The Stake contract (0x03D809...415Abe) is a TUR staking contract with referral rewards. Users first bind an upline via bind(), then call stake(), which burns the staked TUR (sends it to 0xdead) and credits the user with internal power, a weight that determines how much TUR reward the user can later claim.

power is not assigned at a fixed ratio. Instead, getPowerAmount() converts the deposited TUR into a USDT-denominated value by chaining two live AMM prices: TUR/NOBEL and NOBEL/USDT, both read from current pair reserves. The contract also grants bonus power to first- and second-level referrers through _distributeRefPower().

Vulnerability Analysis

The root cause was an unsafe spot-price dependency in the Stake contract. On each deposit, stake() calculates uValue = getPowerAmount(amount), converts it into _power = _uValue * 100, updates the staker's accounting, and then calls _distributeRefPower() to propagate extra power to upstream referrers.

Specifically, uValue is computed as follows:

$u V a l u e = g e t P o w e r A m o u n t (a m o u n t)$

where getPowerAmount() is effectively:

$amount \times \text{TUR/NOBEL spot price} \times \text{NOBEL/USDT spot price}$

The implementation reads those prices directly from current pair reserves via getReserves(), so the staking valuation depends entirely on same-transaction spot prices instead of a manipulation-resistant oracle or TWAP.

This lets an attacker temporarily inflate TUR's on-chain valuation, stake during the manipulated window, and receive exaggerated uValue and power. The referral logic amplifies the damage: _distributeRefPower() grants 20% of the staker's power to the first referrer and 5% to the second referrer, but these extra allocations are not matched by a corresponding rewardDebt update for those referrers. As a result, attacker-controlled referrer accounts can immediately claim disproportionate TUR rewards from the Stake contract.

Attack Analysis

The following analysis is based on the transaction 0x96c9ce3c...81e348.

Step 1: The attacker borrowed 1,900,000e18 USDT from ListaDAO's Moolah contract as flash-loan capital.
Step 2: The attacker used the borrowed capital to manipulate the NOBEL-USDT and TUR-NOBEL pools, temporarily pushing TUR's spot valuation sharply upward.
Step 3: During the manipulated window, the attacker staked 7,770,707e18 TUR into the Stake contract. The transaction emitted a StakeEvent showing a massively inflated uValue of 8,283,864e18 and corresponding power of 828,386,488e18.
Step 4: Because the attacker had already arranged self-controlled referrer accounts, _distributeRefPower() awarded them extra reward power derived from the manipulated stake. The first and second referrers received the expected 20% and 5% referral allocations.
Step 5: The boosted referrer accounts then claimed TUR rewards from the Stake contract. In the same transaction, Stake transferred 15,238,941e18 TUR to 0xFd11...AcEaB and 3,809,924e18 TUR to 0x9007...E550B; both addresses immediately forwarded the same amounts to the attacker. The 4:1 payout ratio matches the contract's 20% versus 5% referral-power split.
Step 6: The transaction also shows claim fees flowing from Stake to the fund wallet 0xb302...89923, consistent with the claim() implementation charging a 3% TUR fee before sending rewards to claimants.
Step 7: After extracting the amplified TUR rewards, the attacker swapped the proceeds back into USDT, repaid the 1,900,000 USDT flash loan, and transferred 133,490e18 USDT to 0xEf67...4e5898 as profit.

Conclusion

This incident was caused by a manipulable reward valuation model in the Stake contract, not by the TUR token's separate LP dividend accounting. By tying staking power and referral rewards to live AMM reserve ratios, the contract allowed a flash-loan-funded attacker to inflate TUR's spot price, manufacture excessive reward power, and drain TUR from the staking contract through self-controlled referral accounts. A safer design would replace spot-reserve pricing with a manipulation-resistant oracle or sufficiently long TWAP and ensure that any referral power increase is paired with consistent reward-debt accounting.

8. EST Token Incident

Brief Summary

On March 27, 2026, the BNBDeposit contract on BNB Chain was exploited for approximately $92.3K due to two issues: a spot-price dependency in BNBDeposit and a flawed burn mechanism in the EST token. The price dependency allowed the attacker to acquire a large amount of EST, and the flawed burn mechanism allowed the attacker to drain the EST-WBNB pool via a sandwich-style manipulation.

Vulnerability Analysis

The root cause of the incident is twofold:

The function onTokenReceived() in the BNBDeposit contract (0xE71547...d29A61) calculated users' claimable amount based on the contract's balance and the spot price of EST, both of which are easily manipulable.
The EST token (0xD4524B...498a91) implemented a flawed burn mechanism that allows an attacker to burn EST in the EST-WBNB pool by directly transferring EST to the pool.

As a result, the attacker leveraged both vulnerabilities to perform a sandwich attack and siphon WBNB from the EST-WBNB pool.

Attack Analysis

The following analysis is based on the transaction 0x2f1c33ea...bd1626.

Step 1: The attacker borrowed 250,000e18 WBNB via Moolah and unwrapped 15e18 WBNB to BNB for the attack.
Step 2: The attacker repeatedly transferred 0.3e18 BNB to BNBDeposit 34 times (total 10.2e18 BNB). Each direct transfer triggered the deposit logic. In this step, the attacker received ~9,100e18 LP tokens (in virtual accounting) and 2.65e18 WBNB as the bonus.
Step 3: The attacker swapped 400e18 WBNB for ~822Me18 EST and set BNBDeposit as the recipient, inflating both BNBDeposit's EST balance and the EST price in the pool.
Step 4: The attacker transferred 1e18 EST to BNBDeposit to trigger the claim mechanism, receiving 20Me18 EST based on the amplified price and balance.
Step 5: The attacker swapped 245,000e18 WBNB for ~330Me18 EST and set BNBDeposit as the recipient.
Step 6: The attacker performed transfer-skim actions ~150 times to continuously burn EST in the EST-WBNB pool.
Step 7: The attacker swapped the remaining EST for 245,560e18 WBNB.
Step 8: The attacker repaid the flash loan and netted 150 WBNB in profit.

Conclusion

This incident was caused by two issues: a spot-price dependency and a flawed burn mechanism. To mitigate similar risks, projects must ensure reliable price oracles and sound token burn logic before deployment.

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