Weekly Web3 Security Incident Roundup | Apr 6 – Apr 12, 2026

During the past week (2026/04/06 - 2026/04/12), BlockSec detected and analyzed four attack incidents, with total estimated losses of approximately $928.6K. The table below summarizes these incidents, and detailed analyses for each case are provided in the following subsections.

*The Denaria incident was not covered in last week's report and is included here for completeness.

Starting this week, we highlight one incident at the top of each report. The selection is not necessarily based on loss amount — it may be chosen for its novel protocol design, clever attack technique, or broader lessons for the community.

Weekly Highlight: Denaria Incident

The perpetual DEX Denaria introduced novel accounting mechanisms backed by complex code logic. Yet, a post-audit refactor introduced a rounding asymmetry that could produce a subtle edge case, a negative value, which ultimately hit an unsafe cast and enabled an astronomical value extraction.

On April 5, 2026, Denaria's perpetual DEX on Linea was exploited for approximately $165.6K in losses. The root cause was two compounding flaws in getLpLiquidityBalance(): a post-audit refactor to LP balance accounting introduced a rounding asymmetry that could produce a slightly negative intermediate value, and an unsafe int256-to-uint256 cast silently wrapped that negative value into a near-maximal unsigned integer rather than reverting. The attacker exploited this through a single-sided LP deposit and a long trade, then withdrew artificially inflated PnL from the vault.

Background

Denaria is a perpetual DEX on Linea built around a dynamic virtual AMM. It separates trading and settlement into two components. The PerpPair market manages user positions and LP accounting, while the Vault holds collateral and settles realized PnL.

LP ownership in PerpPair is not represented by an explicit token balance. Instead, the protocol reconstructs each LP's state from an internal accounting matrix composed of two bookkeeping components, referred to here as the asset side and the stable side. The asset side tracks the LP's share of the pool's exposure to price movements, while the stable side tracks its share of the pool's stable-denominated value. Together, these two components jointly determine how an LP's value is tracked and settled.

Crucially, these components are not stored as static snapshots. Every time a trade occurs, PerpPair updates its global liquidity state, and each LP's reconstructed balance is derived from the difference between cumulative global values and the LP's entry-point snapshot. This accounting mechanism was introduced in a post-audit refactor that replaced the original share-based accumulator with direct balance tracking. However, the refactored subtractive path introduced a rounding asymmetry that could cause reconstructed LP components to become slightly negative under certain trade sequences.

Vulnerability Analysis

The vulnerable PerpPair contract (0xb683...36ae17) contains two compounding flaws.

1. Rounding asymmetry in refactored accounting. The post-audit refactor that introduced direct balance tracking created a rounding asymmetry in the subtractive reconstruction path. Under certain trade sequences, the global cumulative value after rounding could become marginally smaller than the LP's entry-point snapshot, causing the subtraction to produce a small negative result instead of zero. In theory, this value should have been zero or near-zero; the asymmetry was a flaw specific to this refactored implementation, not an inherent property of subtractive accounting in general.

2. Unsafe signed-to-unsigned cast. In getLpLiquidityBalance(), a reconstructed LP balance component was cast from int256 to uint256 without validation. In Solidity, casting a negative int256 to uint256 does not revert; it wraps the value modulo 2^256, turning a small negative number like -1 into a near-maximal unsigned integer (2^256 - 1). Because this reconstructed balance fed into calcPnL() for settlement, any negative input would be interpreted as an enormous LP position, allowing an attacker to realize an artificially inflated profit and drain funds from the vault.

Neither flaw alone would have been exploitable. The rounding asymmetry only produced a slightly negative value, which under normal int256 arithmetic would simply represent a negligible error. But once that negative value reached the unguarded cast, it wrapped into a near-maximal unsigned integer. A subsequent bounds check then capped the wrapped value to the pool's total asset-side liquidity, effectively converting the overflow into a claim over the entire asset side of the market.

Attack Analysis

The following analysis is based on the attack transaction 0xcb0744...0c606447.

• Step 1: The attacker borrowed 60,000 USDC through an Aave flash loan.

• Step 2: A helper address deposited 30,000 USDC as collateral and added a stable-only LP position of 19,980 stable tokens. By depositing only on the stable side, the helper ensured that its asset-side LP component started near zero, making it more susceptible to crossing into negative territory from rounding.

• Step 3: A second helper address deposited 15,000 USDC and opened a 100,000 notional long position, causing a liquidityM update that introduced the key rounding error. The large notional size relative to the pool's liquidity amplified the per-trade rounding impact, pushing the first helper's reconstructed asset-side balance slightly below zero.

• Step 4: The first helper then invoked realizePnL(). During LP balance reconstruction, the negative lpAssetBalance was wrapped to a near-maximal uint256. This large value was then capped to the market's full asset-side liquidity and generated a highly inflated profit. In effect, the protocol believed the LP owned the entire asset side of the market.

• Step 5: The attacker withdrew the inflated PnL from the vault.

The same pattern was repeated until the remaining vault liquidity was drained. After repaying the flash loan, the attacker realized a profit of approximately $165.6K.

Conclusion

This exploit was ultimately caused by missing boundary validation on a signed-to-unsigned conversion. The immediate fix is straightforward: replace the bare cast with SafeCast.toUint256(), which reverts on negative input rather than wrapping it.

More broadly, this incident illustrates the risk of post-audit refactors that bypass external review. According to the official post-mortem, the rounding asymmetry was introduced after the final external audit when the team replaced the original accumulator with direct balance tracking. While the refactor solved an overflow concern, it created a new edge case that internal testing did not catch. When protocols refactor core accounting logic, the new code path should be treated as security-critical and re-audited, particularly when reconstructed values feed directly into PnL settlement or withdrawal logic.

HB Token Incident

On April 7, 2026, HB, a custom ERC-20 token with embedded buy/sell hooks on BNB Chain, was exploited for approximately $193K. The root cause was flawed reward-settlement logic: when triggered, it called swapBack(), which removed HB reserves directly from the PancakeSwap pair and then called sync() to reprice the pool. After the attacker bought out most of the pair's HB, the subsequent swapBack() execution further reduced remaining liquidity and sharply inflated the spot price. The attacker then sold tiny amounts of HB into the distorted pool for disproportionately large amounts of USDT, repeating the cycle until the pair was drained.

Background

HB is a custom ERC-20 token on BNB Chain with buy and sell hooks embedded in _transfer(). When users buy from the AMM pair, _handleBuy() records cost basis information. When users sell, _handleSell() branches into different tax and settlement paths depending on the state of the pair.

The token also includes a reward-settlement mechanism that can trigger swapBack(). Rather than performing a normal router-mediated swap, swapBack() transfers HB directly from the PancakeSwap pair to the PROOF address, then forces the pair to resynchronize via sync(). This allows the contract to shrink the pair's HB reserves outside normal AMM trading flows and immediately reprice the pool upward.

Vulnerability Analysis

The core flaw in the HB token contract (0x62ce...87a4b0) was that swapBack() sourced rewards by pulling tokens directly from the AMM pair rather than from a treasury or through a router-mediated swap. Because swapBack() was reachable through the reward-settlement path, a non-trading code path could directly mutate pair reserves and alter the spot price.

When the pair's HB reserves are low, a swapBack() invocation further reduces the remaining HB and amplifies the price distortion, making it possible to sell tiny amounts of HB at extremely inflated prices.

Attack Analysis

The following analysis is based on the attack transaction 0x19671f...d71594ed.

• Step 1: The attacker borrowed large amounts of funds from Venus.

• Step 2: The attacker transferred approximately 1,496 HB into the token contract, increasing the contract's HB balance so that the subsequent swapBack() could pull a larger amount from the pair.

• Step 3: By transferring a tiny amount of HB into the PancakeSwap pair, the attacker triggered _swapAndLiquify(), which swapped roughly 4,163 HB held by the token contract for 10 USDT and increased the attacker's claimable HB rewards.

• Step 4: The attacker then spent 72,117,360 USDT to buy 73,608,753 HB, leaving the pair with very little remaining HB liquidity.

• Step 5: Next, the attacker triggered the reward shortfall path. To satisfy rewards, the token invoked swapBack(), which pulled additional HB from the PancakeSwap pair and forced sync(), sharply increasing the HB price.

• Step 6: The attacker directly transferred USDT into the pair to replenish its USDT reserves, then sold only 0.000582 HB for 37,582,322 USDT at the distorted price.

By repeating Step 6 to sell HB tokens at a distorted price, the attacker extracted nearly all USDT from the pool.

Conclusion

The HB token incident illustrates how dangerous it is to allow reward logic to mutate AMM reserves directly. Reserve-affecting functions should never be reachable from reward-settlement paths, and protocols should avoid conflating internal token balances with AMM reserve accounting in security-sensitive control flow. Any design that relies on spot AMM pricing after internally perturbing the pool is inherently vulnerable to price manipulation.

Squid Multicall Incident

On April 7, 2026, a Squid user lost approximately $517K across multiple chains in an approval-related incident. The user mistakenly approved a SquidMulticall contract instead of the intended Squid Router. This allowed the attacker to invoke a permissionless SquidMulticall.run() function to execute arbitrary external calls. The attacker could therefore use any allowance approved to the contract to execute token transferFrom() calls against users who had approved it.

Background

In Squid's normal flow, users should approve the Squid Router, while SquidMulticall acts only as an execution helper. The helper contract is designed to execute batched calls as part of routing logic, but it should not be the spender that users directly approve for token transfers.

Because ERC-20 allowance checks are performed only against the spender address, any contract that combines user approvals with unrestricted arbitrary-call capability creates a dangerous approval sink: once approved, that contract can become a generic token-withdrawal vector if anyone can control what calls it makes.

Vulnerability Analysis

This incident was not caused by a smart contract vulnerability. The loss resulted from two conditions occurring together: a mistaken approval targeting SquidMulticall instead of the Router, and run()'s permissionless design accepting arbitrary targets and calldata from any caller.

SquidMulticall is intended to execute batched calls as a downstream step in the Router's flow, where inputs are constructed by trusted routing logic. Used as intended, the permissionless design poses no risk. But a misplaced approval changes that entirely: an MEV bot detected the live allowance, called run() with crafted calldata to invoke transferFrom(victim, attacker, amount), and drained the approved tokens across each chain without any further action from the victim.

Attack Analysis

The incident affected a user across BNB Chain, Arbitrum, Optimism, Avalanche, and Base. The following analysis is based on the attack transaction 0x81d0c4...9b1301e9.

• Step 1: The victim (0xacc0...f40e98) mistakenly approved SquidMulticall rather than the intended Squid Router.

• Step 2: An MEV bot detected this allowance and invoked SquidMulticall.run() with crafted calldata.

• Step 3: Through the arbitrary call, SquidMulticall invoked transferFrom(victim, attacker, amount) and transferred approved assets out of the victim's wallet.

Conclusion

This incident illustrates the risk of permissionless arbitrary-call contracts coexisting with user-facing approval flows. The immediate cause was a mistaken approval, and because SquidMulticall accepted unrestricted callers, arbitrary targets, and arbitrary calldata, any approval mistakenly directed at it was immediately and fully exploitable. Protocols that use execution helper contracts should consider adding caller restrictions or constraining the call targets permitted by such functions, so that a misplaced approval cannot be trivially weaponized.

XBIT Incident

On April 11, 2026, the XBIT token on BNB Chain was exploited for approximately $53K. The root cause was a fail-open access control flaw in XBITVault: the transfer() function's authorization check was conditional — it only enforced msg.sender == xbitContract when xbitContract was non-zero, and silently passed otherwise. Because bindXBIT() had never been called to initialize the contract, this flaw was permanently exposed, allowing arbitrary callers to move XBIT balances from any address, including the XBIT/USDT PancakeSwap pair. The attacker used this to drain XBIT from the pair, then repeatedly sold tiny amounts of XBIT back into the pool for disproportionately large amounts of USDT.

Background

XBITVault is not a passive treasury contract. It is the balance and allowance backend for the XBIT token system, exposing token-like functions such as transfer(), approve(), and mintForXBIT(). Under the intended design, the owner must first call bindXBIT() to initialize the vault by setting xbitContract, pancakePair, pairContract, and xbitDecimals. After initialization, sensitive state-changing functions are supposed to be callable only by the bound XBIT contract. In other words, the vault's security model depends on successful initialization before public use.

Vulnerability Analysis

The critical flaw is that the access control is conditional in the vulnerable XBITVault contract (0xc879...42391a). The transfer() function only checks msg.sender == xbitContract when xbitContract != address(0). This means the function does not revert when xbitContract is unset, and instead becomes publicly callable by anyone. Because balances are stored in _balances, any external caller can move XBIT from any address to any other address as long as the source address has sufficient balance.

The intended initialization path was bindXBIT(), but because it was never called, the vault stayed in an uninitialized and fail-open state. The result was effectively an unrestricted arbitrary balance transfer primitive.

Attack Analysis

The following analysis is based on the attack transaction 0xbc877f...4df1b694.

• Step 1: Via the unrestricted transfer() function, the attacker moved 1,526,216.569 XBIT out of the XBIT/USDT pair without providing any corresponding USDT.

• Step 2: The attacker invoked sync() to collapse the pair's XBIT reserves to just 1-2 units.

• Step 3: After the pair was left with near-zero XBIT liquidity, the attacker repeatedly sold XBIT, draining approximately 53,112 USDT from the pair.

Conclusion

This incident was caused by an initialization-dependent access control check that failed open. transfer() was unrestricted whenever xbitContract was unset, and because bindXBIT() was never called, the vault permanently exposed a public arbitrary-balance-transfer primitive. Privileged functions should revert until initialization is complete, and deployment-time binding steps should be on-chain enforced prerequisites rather than operational assumptions.

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