Weekly Web3 Security Incident Roundup Logs $1.53M in March Exploits

BlockSec’s weekly Web3 security incident roundup for March 23 through March 29, 2026 recorded eight attacks with about $1.53 million in estimated losses, and the pattern behind the damage matters more than the raw total. This Web3 security incident roundup shows that the biggest failures still came from avoidable contract design mistakes, including spot-price dependency, flawed token burns, broken accounting separation, and callback order that left state exposed to reentrancy.

The week’s losses were concentrated in protocols that treated mutable state as trusted input

The headline figure from BlockSec’s March 23-29 incident roundup was about $1.53 million, but the deeper signal was how tightly the losses clustered around protocols that let adversaries shape the variables used to calculate value. The BCE token incident alone accounted for about $679,000, while Cyrus Finance lost about $512,000. Together they represented the bulk of the reported damage. That concentration matters because these were not abstract failures in market conditions or random one-off bugs. They were direct outcomes of contracts that read manipulated reserves, trusted live pool state, or let user-influenced variables decide how much value should be redeemed from shared liquidity. The same theme showed up in smaller incidents too. A low-dollar exploit can still reveal the same engineering habit that later produces a seven-figure drain. That is why the takeaway is broader than one bad week. DeFi still ships code that behaves as if state remains honest while an attacker is changing it in the same transaction. Readers tracking exploit patterns in Web3 Fraud Files should read this week less as a collection of isolated attacks and more as a reminder that adversarial execution remains underpriced in production contract design.

Spot-price dependency kept turning AMM pools into extraction tools

The clearest pattern in the roundup was misuse of current AMM state as if it were a safe oracle. In the Cyrus Finance exploit, BlockSec said the protocol’s `withdrawUSDTFromAny()` path read PancakeSwap V3 `slot0()` and used that live price to estimate the value of a user’s liquidity share during exit. Because `slot0()` can be manipulated inside the same transaction, the attacker was able to distort the valuation of the CYRP NFT position and redeem more than the position’s fair value. A similar dependence on immediate reserve state appeared in the EST token exploit, where a broken burn path and price-sensitive logic let the attacker chain manipulation into profit. This problem has been documented for years. Uniswap’s oracle documentation explains why historical observations exist instead of relying on raw spot reads, and Chainlink’s price feed documentation makes the same point from the oracle side by using aggregated external data rather than single-pool state. Yet teams still write withdrawal or reward formulas that translate a temporary price move into permanent entitlement. That is not an oracle problem. It is a contract-design problem. Builders following our Web3 Builder coverage should see this as a warning that AMMs are not neutral data sources when the user calling the function can also move the pool.

Token design flaws showed how transfer logic can quietly become a pool attack surface

The BCE token incident showed a different but equally damaging class of failure. According to BlockSec, the token’s `scheduledDestruction` variable could be influenced by trading activity and later executed in a way that burned tokens from the PancakeSwap pair rather than from the seller’s balance. That distinction is everything. Once the pair itself becomes the settlement target, the attacker is no longer just trading against liquidity. The attacker is editing liquidity. By compressing the pool’s BCE reserve, the exploit distorted price formation and let the attacker drain USDT at a manipulated rate. This is a design flaw dressed up as tokenomics. The same week also included other token-logic issues, including the EST exploit, which mixed token design weakness with spot-price dependency, reinforcing the point that many token contracts still contain invisible assumptions about who ultimately bears cost. When those assumptions are wrong, the pair contract becomes the victim. Data and monitoring can show the reserve move after the fact, but the root cause sits inside the token itself. That is why token transfer logic deserves the same scrutiny as lending math or vault accounting. In the current market, any project that treats transfer-side mechanics as secondary engineering is effectively creating its own exploit surface long before users discover it in production.

Basic Solidity safety rules still would have prevented multiple Ethereum exploits

Two Ethereum incidents in the roundup looked almost outdated, which is exactly why they stand out. One contract was exploited for about $97,000 because a function summed attacker-controlled values without overflow protection, allowing `uint256` wraparound and a full USDT drain for the cost of 1 wei. Another contract lost about $11,000 because it updated liquidity-related state before settlement and invoked an external callback with no reentrancy guard, allowing nested calls to inflate recorded liquidity before the final balance check completed. These are textbook failures. Solidity 0.8.0 added checked arithmetic so that overflows revert by default, and OpenZeppelin’s security guidance has long emphasized reentrancy guards and the checks-effects-interactions pattern. Yet incidents like these keep appearing because teams often spend more time refining product behavior than defending execution order and arithmetic correctness. That remains a mistake. If a contract cannot survive manipulated inputs or nested execution, it does not matter how elegant the surrounding protocol is. For readers scanning recent Crypto Newswire developments around institutional DeFi and capital formation, this matters because serious capital does not care whether a flaw is basic or advanced. It only cares whether funds can be drained.

Shared accounting domains kept creating redemptions the protocols never economically supported

The smallest incidents in the roundup may have carried the cleanest engineering lesson. BlockSec described one BNB Chain staking exploit where `stake2()` and `withdraw3()` interacted through shared accounting variables even though the two paths handled different token baskets and different ratios. That let the attacker deposit through the lighter mode and redeem through the heavier one, pulling out excess value on each loop. In the MYX `sMYX` case, repeated transfers between attacker-controlled addresses inflated the profit-per-share variable and reduced recorded supply in a way that created dividends without any real inflow backing them. The economic logic was imaginary, but the payout path was real. These examples point to a common weakness that often hides beneath more visible exploit types: protocols treat balances as interchangeable across deposit modes, reward modes, or share modes when the underlying obligations are not interchangeable at all. Once one accounting domain can redeem against another, attackers do not need privileged access. They only need a path mismatch. The lesson is not just to audit functions individually. It is to verify that each asset basket, reward accumulator, and withdrawal route remains isolated unless the protocol can prove equivalence. Without that isolation, what looks like flexible product design turns into a standing extraction loop.

This roundup argues for specification discipline, not just faster monitoring

Runtime detection is getting better. BlockSec identified and analyzed eight incidents in a single week, which shows how far monitoring and transaction forensics have come. But this roundup also shows the limit of security systems that react after the vulnerable logic is already live. Monitoring can flag abnormal swaps, reserve collapses, or suspicious transfer loops. It cannot fix a redemption formula that trusts live pool state, a token burn mechanism that charges the pair instead of the trader, or a staking system that reuses variables across incompatible modes. The next improvement curve in DeFi security will come from writing tighter specifications before deployment. Protocols need explicit rules for how value enters and exits the system, which variables can influence entitlement, how supply changes map to real assets, and which state transitions must remain impossible even under flash-loan pressure. That work is less visible than a real-time dashboard, but it is where the money is won or lost. The March 23-29 incident set suggests that the sector does not have a shortage of monitoring tools. It still has a shortage of contracts designed around hostile execution from the first line of code.

The more mature protocols get, the less room there is for security failures that stem from basic assumptions about price reads, supply accounting, or settlement order. The next wave of credible DeFi infrastructure will come from teams that treat adversarial execution as a design input rather than a post-launch surprise, because the market is getting faster at forgiving volatility than it is at forgiving preventable contract logic.

This article is for informational purposes only and does not constitute financial or investment advice.