Weekly Web3 Security Incident Roundup | Mar 2 – Mar 8, 2026

During the past week (2026/03/02 - 2026/03/08), BlockSec detected and analyzed seven attack incidents, with total estimated losses of ~$3.25M. 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/01*	BUBU2 Incident	Token design flaw	~$19.7K
2026/03/02	ACPRoute Incident	Flawed business logic	~$58K
2026/03/02	sDOLA Llamalend Market Incident	Price manipulation	~$239K
2026/03/03	The V4 Router by z0r0z Incident	Flawed business logic	~$42K
2026/03/05	The BitcoinReserveOffering Contract Incident	Flawed business logic	~$2.7M
2026/03/07	MoltEVM Incident	Flawed business logic	~$127K
2026/03/08	LEDS Incident	Flawed business logic	~$64K

*The BUBU2 incident was missed in last week's report and is included here for completeness.

1. BUBU2 Incident

Brief Summary

On March 1, 2026, the BUBU2 token on BNB Chain was exploited, resulting in approximately $19.7K in losses. The root cause was a token design flaw: the contract embeds a time-accumulated deflationary mechanism that directly deducts tokens from the AMM pair's reserves upon transfer. The contract owner shortened the trigger interval to an unreasonably small value before the attack, causing hundreds of burn rounds to accumulate and execute in a single call. The attacker leveraged a flash loan to trigger this mechanism, collapsing the pair's reserves and inflating the token price, then reverse-swapped at the distorted rate for profit.

Background

BUBU2 is a deflationary ERC-20 token protocol deployed on BNB Chain. The protocol embeds a periodic deflationary engine controlled by burnAndMintSwitch: once enabled by the owner via setBurnAndMintSwitch(true), any non-exempt transfer that triggers the _update() hook will invoke _triggerDailyBurnAndMint(), which burns tokens proportionally from the trading pair's BUBU2 balance based on the number of TRIGGER_INTERVAL periods elapsed since the last trigger, and syncs the reserves accordingly.

Vulnerability Analysis

The root cause is a design flaw in the BUBU2 token contract (0x3fF3...ee52). The contract embeds a periodic deflationary mechanism in its _update() hook: when triggered, `_triggerDailyBurnAndMint()` calculates the number of `TRIGGER_INTERVAL` periods elapsed since the last execution, and burns a proportional amount of `BUBU2` directly from the trading pair ([0x7745...cd2f](https://bscscan.com/address/0x774547ea9d2a0cc79db3288f61e989f1b06bcd2f)), followed by a sync() to update reserves. Critically, the owner can reconfigure TRIGGER_INTERVAL without any timelock or minimum-bound protection.

Prior to the attack, the owner called setBurnAndMintSwitch(true) and then setTriggerInterval(120), compressing the interval from the default 6 hours to 120 seconds. Because lastTriggerTime was still anchored several hours in the past, the next trigger computed hundreds of accumulated rounds, and the burn amount scaled linearly with rounds. This caused a single transfer to drain a massive amount of BUBU2 from the pair, collapsing its reserves and inflating the token price by approximately 11x.

Attack Analysis

The following analysis is based on the transaction 0x1bc0...141c,0x191c...1ee4,0xd6e5...51a6.

Step 1: The token owner first enabled the periodic deflationary mechanism via setBurnAndMintSwitch(true), then shortened the trigger interval from the default 6 hours to 120 seconds via setTriggerInterval(120). The attacker subsequently borrowed 18 WBNB via a flash loan and swapped it for approximately 18,715,856 BUBU2 from the pool.

Step 2: The attacker initiated a small transfer, triggering _triggerDailyBurnAndMint(). The pool's BUBU2 balance dropped by approximately 1,025,988,664e18 tokens, leaving only 6,493,352e18 BUBU2 remaining in the reserve after sync() executed, which inflated the BUBU2 price by approximately 200x.

Step 3: The attacker sold the BUBU2 acquired in Step 1 back into the pool at the inflated price, receiving approximately 50 WBNB. After repaying the flash loan, the net profit was approximately 32 WBNB.

Conclusion

The BUBU2 exploit stemmed from a critical design flaw in the token contract. The owner configured an unreasonably small TRIGGER_INTERVAL, which allowed elapsed time to accumulate into hundreds of rounds and drain the trading pair's reserves in a single call, causing a violent spike in the BUBU2 price.

To reduce similar risks in the future:

Protect critical parameters like TRIGGER_INTERVAL with bounds or timelocks.
Limit or cap accumulated execution rounds.

2. ACPRoute Incident

Brief Summary

On March 2, 2026, the ACPRoute protocol on Base was exploited, resulting in approximately $58K in losses. The root cause was flawed business logic in the payment manager contract: job state was loaded as a memory copy instead of a storage reference, so cumulative disbursement tracking was never persisted on-chain. This allowed the attacker to create a job, trigger automatic payment release during the phase transition, and then claim the same escrowed funds a second time through a permissionless claim function.

Background

ACP (Agent Commerce Protocol) is a modular on-chain commerce protocol designed for client and provider interactions. It structures activity into three layers: Accounts, Jobs, and Memos. Jobs follow a fixed lifecycle (REQUEST → NEGOTIATION → TRANSACTION → EVALUATION → COMPLETED), and payments are held in escrow by the PaymentManager contract during the TRANSACTION phase. When a job reaches COMPLETED, the protocol releases escrowed funds to the provider via the function releasePayment(). To prevent double-claiming, the protocol tracks cumulative disbursements per job using the amountClaimed field on the Job struct. Each call to the function releasePayment() is expected to compare the requested amount against amountClaimed to ensure funds are only released once.

Vulnerability Analysis

The root cause lies in the releasePayment() function of the PaymentManager contract (0x56c3...0684), where job state is loaded as a memory copy rather than a storage reference. Although the protocol tracks cumulative disbursements via amountClaimed to prevent double-claiming, the increment job.amountClaimed += amount operates solely on a transient local copy and is never written back to on-chain storage. Consequently, every invocation of the function releasePayment() observes amountClaimed == 0, allowing an attacker to call the function claimBudget() and drain the victim contract (0x307e...d6e8) a second time after the phase transition has already triggered the function releasePayment() automatically.

Attack Analysis

The following analysis is based on the transaction 0xe94a...f9a0.

Step 1: The attacker borrowed 97,000e6 USDC via flash loan as the capital for the subsequent attack.
Step 2: Inside the callback, the attacker called the function createJob() on the ACPRouter, while deploying a fresh provider contract (0x1ee502dd...) to receive the funds.
Step 3: The attacker repeatedly called the function createMemo() and invoked the provider contract's own exec() to advance the job phase, until the COMPLETED phase transition was triggered, automatically calling the function releasePayment() and releasing the full balance to the provider contract. At this point amountClaimed should have been updated, but its value in storage remained 0.
Step 4: The attacker called the function claimBudget() and successfully claimed the escrowed 97,000e6 USDC a second time as profit.

Conclusion

This incident was caused by a state persistence flaw that allowed escrowed funds to be claimed twice within the same job lifecycle.

To reduce similar risks in the future:

Ensure critical state variables (e.g., amountClaimed) are updated using storage references.
Restrict sensitive payout functions or enforce strict state validation before execution.

3. sDOLA Llamalend Market Incident

Brief Summary

On March 2, 2026, the sDOLA Llamalend Market on Ethereum was exploited, resulting in approximately $239K in losses. The root cause is price manipulation. Specifically, sDOLA is an ERC4626 token whose price can be manipulated via donate(). Llamalend is an AMM-based lending market, and due to LLAMMA's mechanism, users can still become liquidatable even when the collateral price rises. Therefore, an attacker can use donate() to push up the sDOLA price, drive users' position health below zero, and then liquidate those users for profit.

Background

LLAMMA (Lending-Liquidating AMM Algorithm) is an AMM-based lending market used by Curve [1]. Unlike traditional lending protocols, LLAMMA places user collateral into price bands within the AMM. As the oracle price $P\\_{oracle}$ moves, collateral is progressively converted between the collateral token and crvUSD through arbitrage-driven swaps across bands (soft liquidation), gradually de-risking positions instead of triggering abrupt liquidations.

If soft liquidation cannot de-risk a position fast enough, hard liquidation kicks in [2], which is triggered when a position's health drops below zero. Health is computed via get_x_down() [3], which does not simply mark the collateral to market. Instead, it simulates a round-trip conversion of the user's position to assess its recoverable value. This round-trip uses two different price anchors: one derived from the current $P\\_{oracle}$ (moves with the live oracle), and another derived from the user's band boundaries (fixed when the position was created).

Vulnerability Analysis

The buggy contracts include the crvUSD Controller (0xad44...fb86) and the LLAMMA AMM (0x0079...a1f7). The victim contract is the sDOLA Llamalend market (0x2b08...4fbe).

sDOLA is an ERC4626 vault token whose share price is determined by the ratio of total assets to total shares. Because anyone can call donate() to add assets to the vault, the share price can be inflated within a single transaction. This is the manipulable oracle that LLAMMA's health function depends on.

As described in Background, get_x_down() computes health by simulating a round-trip conversion through two price anchors: one derived from $P\\_{oracle}$ (dynamic, moves with the live oracle), and another derived from the user's band boundaries (static, fixed at position creation). The protocol does not apply any delay or sanity check when reading $P\\_{oracle}$ . Therefore, when the oracle price is inflated, the dynamic anchor rises but the static anchor stays the same. In effect, the simulation converts crvUSD to collateral at the inflated oracle price and converts back at the original band price, so the assessed recoverable value shrinks as the gap between the two anchors widens. This drives health below zero, even though the collateral price has risen.

Attack Analysis

The following analysis is based on the transaction 0xb935...d8a4.

Step 1: Manipulate LLAMMA state (large swaps) to move active_band and push many users into x only posture (only crvUSD).

Step 2: Manipulate sDOLA's price via donations, then use a zero-amount swap (swap(0)) to write the manipulated price into the AMM pool.

Step 3: Trigger health recomputation through users_to_liquidate() -> _health() -> get_x_down().
Step 4: Because get_x_down() computes recoverable value through two divergent price anchors (the dynamic anchor, now inflated, versus the static anchor, unchanged), the round-trip conversion produces a haircut on the effective value, and many positions cross below zero health.
Step 5: Batch hard-liquidate those users for profit.

Additionally, the trace includes two create_loan() calls. The first loan was mainly used to fund large-size crvUSD swap operations. The second loan was used to obtain crvUSD to repay the debt of the first position and recycle capital. These two loans are mostly financing/settlement legs and are not the core exploit steps themselves.

Conclusion

The incident is a collateral price manipulation attack. The attacker manipulated sDOLA price in-transaction and, due to LLAMMA's path-based health mechanism, pushed users into liquidation conditions. A key consequence is that positions can still become liquidatable even when collateral price increases. Recommended hardening directions:

Use delayed or TWAP collateral prices for liquidation.

References

[1] Curve crvUSD LLAMMA docs: [https://dev.curve.finance/crvUSD/amm/#bands](https://dev.curve.finance/crvUSD/amm/#bands)
[2] Curve LLAMMA liquidation explainer: [https://dev.curve.finance/crvUSD/llamma-explainer/#liquidation](https://dev.curve.finance/crvUSD/llamma-explainer/#liquidation)
[3] Curve stablecoin whitepaper: [https://docs.curve.finance/pdf/whitepapers/whitepaper\_curve\_stablecoin.pdf](https://docs.curve.finance/pdf/whitepapers/whitepaper_curve_stablecoin.pdf)

4. The V4 Router by z0r0z Incident

Brief Summary

On March 3, 2026, the V4 Router by z0r0z on Ethereum was exploited, resulting in approximately $42K in losses. The attack was caused by flawed authorization logic in swap(), where the router relied on a fixed calldata offset in inline assembly to verify that the payer matched msg.sender. Because ABI encoding for dynamic types does not guarantee a fixed layout, the attacker was able to craft non-standard but valid calldata that bypassed the check, impersonated a previously approved victim as the payer, and redirected the swap output to an attacker-controlled address.

Background

The protocol inherits from the Uniswap v4 Router and overrides some of its methods. In essence, it functions as a swap router, allowing users to avoid interacting directly with the corresponding pool and instead use the router as a unified entry point.

Vulnerability Analysis

The root cause is flawed business logic in the V4 Router contract (0x0000...ce97). The victim contract is 0x65a8...7675. The swap() function accepts two parameters: data (bytes) and deadline (uint256). Within the function, an authorization check uses an inline assembly block to compare calldataload(164) with caller(), ensuring that the payer encoded in data matches msg.sender. The protocol assumes that the bytes offset is always 0x40, placing the payer at byte position 164 (0xa4).

However, ABI encoding does not guarantee this layout: dynamic parameters store only an offset in the head, and that offset may legally point to any aligned location in calldata. By crafting a valid but non-standard encoding where the bytes offset is moved to 0xc0, an attacker can insert arbitrary padding between the head and the actual tail. The attacker places their own address at byte position 164 to pass the assembly check, while the true bytes payload at the relocated tail encodes the victim's address as payer. By selecting a victim who has previously approved the router and setting the receiver to their own address, the attacker can redirect the swap output and steal funds.

Attack Analysis

The following analysis is based on the transaction 0xfe34...466a.

Step 1: Select a user who has previously approved the router as the target.
Step 2: Craft the calldata to bypass the authorization check.
Step 3: Specify the victim as the payer in data, set the attacker's own address as the token receiver, and then steal the victim's assets.

Conclusion

This incident was caused by relying on a hardcoded calldata offset for authorization in the swap path. Because ABI encoding for dynamic types does not guarantee a fixed layout, the attacker bypassed the check with non-standard but valid calldata, impersonated an approved victim as the payer, and redirected the swap output.

To reduce similar risks in the future:

Never rely on hardcoded calldata offsets for dynamic ABI-encoded parameters.
Decode and validate structured inputs using canonical ABI decoding instead of manual positional assumptions.
Ensure that the actual payer, receiver, and token flow are consistently validated against the intended caller and execution context.

5. The BitcoinReserveOffering Contract Incident

Brief Summary

On March 5, 2026, the BitcoinReserveOffering contract on Ethereum was exploited, resulting in a loss of approximately $2.7 million. The root cause was flawed business logic: when processing a full ERC-3525 SFT deposit, the minting logic was executed twice within a single call, once during a transfer callback and once in the main flow. The attacker exploited this double-minting behavior through repeated burn-and-mint cycles, exponentially inflating their BRO token balance, and then redeemed the excess for SolvBTC to realize the profit.

Background

BitcoinReserveOffering is a wrapper contract that converts ERC-3525 SFT positions into transferable ERC-20 BRO tokens. Users can call the mint() function to deposit eligible SFTs, and the contract will mint a corresponding amount of BRO based on a configured exchange rate. If a user deposits only part of an SFT's value, the contract transfers the specified amount into its internally held position and then mints the corresponding value of BRO. If a user deposits an entire SFT, the contract transfers the full token into the wrapper contract and mints BRO based on the SFT's total value. Users can later call the burn() function to redeem BRO back into its corresponding ERC-3525 SFT position, converting the wrapped ERC-20 value back into an SFT position.

Vulnerability Analysis

The root cause is that the BitcoinReserveOffering contract (0x15f7...cfcf) executes the minting logic twice when processing a full ERC-3525 SFT deposit in the mint() function. Specifically, in the amount_ == sftBalance branch, mint() calls ERC3525TransferHelper.doSafeTransferIn() to safely transfer the entire SFT into the contract, which triggers the onERC721Received() callback. Inside this callback, the contract already calculates the SFT's value and mints BRO to the sender. After the callback returns, mint() continues execution, recalculates the value using the same amount_, and performs a second _mint(msg.sender, value) operation. This double-minting behavior allows an attacker to repeatedly inflate their BRO balance through a burn-and-mint loop.

Attack Analysis

The following analysis is based on the transaction 0x44e6...958d.

Step 1: The attacker transfers 135e18 BRO tokens into the attack contract as seed capital.
Step 2: The attacker executes the following loop:

Wrap 135e18 BRO tokens into an SFT token.
Call mint() with the full SFT value, which triggers the onERC721Received() callback and mints 135e18 BRO tokens; the outer mint() then continues and calls _mint() again, resulting in a double mint of 270e18 BRO tokens total.
Wrap the 270e18 BRO tokens back into an SFT token.

Step 3: After repeating Step 2 22 times, the attacker accumulates approximately 567,758,816e18 BRO tokens, which are ultimately redeemed for 38e18 SolvBTC as profit.

Conclusion

This incident was caused by double-minting during full SFT deposits, allowing the attacker to exponentially inflate their BRO balance through repeated burn-mint cycles and redeem the excess for SolvBTC.

To reduce similar risks in the future:

Ensure asset accounting occurs only once per deposit operation.
Add invariant checks to prevent mint amounts from exceeding the underlying deposited value.

6. MoltEVM Incident

Brief Summary

On March 7, 2026, the MoltEVM protocol on Base was exploited, resulting in approximately $127K in losses. The root cause was flawed access control logic in the token contract: the privileged minting function was guarded by a modifier that only checked whether the caller was a contract with a specific interface, which could be trivially spoofed. The attacker deployed a malicious contract to bypass the check, minted a large supply of tokens, and dumped them through the liquidity pool for profit.

Background

MoltEVM is an experimental ERC-20 token protocol deployed on Base that explores a self-replicating token model. The system allows a token to spawn new child tokens ("Moltling" tokens) once certain reserve thresholds are reached. When a new Moltling is created, an initial token supply is distributed through the mintFromSpawner() function, and liquidity is seeded automatically to establish a trading market for the new token. This design enables the protocol to expand its token lineage autonomously, with each generation of tokens capable of spawning further descendants.

Vulnerability Analysis

The vulnerability lies in the access control logic of the mintFromSpawner() and setExemptFromSpawner() functions in the MoltEVM contract (0x225d...501f). Both functions rely on the onlySpawnerToken modifier, which was intended to restrict calls to legitimate Moltling contracts spawned by the protocol.

However, the modifier performs only two weak checks: it verifies that msg.sender is a contract and that calling initialized() on the caller returns true. Because these conditions can be trivially satisfied by any arbitrary contract implementing the same interface, the check does not provide meaningful authentication of legitimate spawner tokens.

As a result, an attacker can deploy a minimal contract that simply implements an initialized() function returning true. Once deployed, the malicious contract can freely call mintFromSpawner() to mint arbitrary amounts of tokens and can also invoke setExemptFromSpawner() to whitelist attacker-controlled addresses. This effectively grants the attacker full control over the minting path and allows newly minted tokens to be dumped into liquidity pools for profit.

Attack Analysis

The following analysis is based on the transaction 0x10b7...e03d.

Step 1: The attacker deployed a minimal contract implementing a single initialized() function hardcoded to return true, which was sufficient to pass the onlySpawnerToken modifier check.
Step 2: The attacker's contract called the setExemptFromSpawner() function guarded by the same vulnerable onlySpawnerToken modifier to add the attacker's address to the tax exemption whitelist. This ensured that subsequent large-scale token dumps would not trigger sell taxes or the internal swap logic, maximizing profit.

Step 3: The attacker repeated the setExemptFromSpawner() + mintFromSpawner() function sequence against mEVM first, followed by multiple Moltling child tokens including CSPAWN, CCUTTL, LWORM, and NHYDRA, batch-minting tokens across all targets and dumping them into their respective liquidity pools to extract profit.

Conclusion

This incident was caused by insufficient access control on privileged minting and configuration functions, allowing an attacker to impersonate a legitimate spawner and mint arbitrary tokens for profit.

To reduce similar risks in the future:

Enforce strict access control for privileged minting or configuration functions.
Avoid relying on easily spoofed contract checks for authorization.
Validate caller identity through explicit whitelists or trusted contract registries.

7. LEDS Incident

Brief Summary

On March 8, 2026, the LEDS token on BNB Chain was exploited, resulting in approximately $64K in losses. The root cause was flawed business logic: the token contract exposes multiple independent deflationary mechanisms, each capable of burning tokens directly from the liquidity pair, and none are protected by access control or cooldown. The attacker chained all burn paths within a single transaction, collapsing the pair's LEDS reserve to near zero while the WBNB reserve remained intact, then performed reverse swaps to drain the imbalanced pool for profit.

Background

LEDS is a deflationary token on BNB Chain with built-in fee-on-transfer mechanics. Its _transfer() implements multiple burn mechanisms designed to gradually reduce supply and support price: a daily burn function triggerDailyBurnAndMint(), a deferred burn via stor_18 accumulation on sells, and a special branch that burns tokens to 0xdead when the swap receiver is set to the PancakeSwap Router. The token also features a deposit() function where users send BNB to mint LEDS and provide liquidity, earning LP rewards claimable through a distributor.

Vulnerability Analysis

The root cause is flawed business logic in the LEDS token contract (0xfb62...a48f). The victim is the LEDS/WBNB pair (0xd109...6f3f). The token implements multiple deflationary mechanisms: triggerDailyBurnAndMint(), sell-path stor_18 accumulation, and a to == router burn branch in _transfer(). Each of these independently removes LEDS from the liquidity pair and calls sync() to update reserves.

While individually these mechanisms serve as gradual deflation tools, they can be chained together within a single transaction to compound their effects. Additionally, the public function 0x17a06174() allows anyone to flush the entire accumulated stor_18 balance at will, with no access control or rate limiting. By sequentially stacking these burn paths, an attacker can reduce the pair's LEDS reserve to near zero while leaving the WBNB reserve untouched, creating an extreme price dislocation exploitable via reverse swaps.

Attack Analysis

The following analysis is based on the transaction 0x2608...79da.

Step 1: The attacker obtained a large amount of WBNB via flash loans (Moolah + Venus collateral borrowing + Aave + PancakeSwap V4).
Step 2: Performed multiple deposit() calls to accumulate LP rewards, then triggered triggerDailyBurnAndMint(), which burned a portion of LEDS from the pair and sent rewards to the distributor, reducing the LEDS reserve in the pool.

Step 3: Called function 0xde1b1942() to claim the accumulated LEDS token rewards.

Step 4: Sold the claimed LEDS for WBNB. Since the pair's LEDS balance exceeded the threshold after the sell, the transferred amount was accumulated into stor_18 (pending burn).

Step 5: Bought LEDS via PancakeSwap with the receiver set to the Router address. This triggered a special branch in _transfer() that burned the purchased LEDS directly from the pair to 0xdead, further reducing the pool's LEDS reserve.

Step 6: Called function 0x17a06174(), which burned the entire stor_18 balance (accumulated in Step 4) from the pair to 0xdead and called sync(), collapsing the pool's LEDS reserve to just 2 wei.

Step 7: Performed reverse swaps to drain WBNB from the now heavily imbalanced pool, repaid all flash loans, and profited 104.56 WBNB ($64K).

Conclusion

This incident was caused by multiple unguarded deflationary mechanisms that can be chained within a single transaction to catastrophically deplete the liquidity pair's reserves.

For any token contract that implements deflationary or auto-burn mechanics, developers should:

Never expose burn from pair functions without proper access control, rate limiting, or cooldown enforcement.
Avoid allowing multiple independent burn mechanisms to be triggered sequentially within a single transaction.

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