Weekly Web3 Security Incident Roundup | Apr 13 – Apr 19, 2026

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

Weekly Highlight: KelpDAO

This incident is highlighted for its novel infrastructure-level attack vector (RPC poisoning against the sole DVN rather than smart contract exploitation), its cascading impact across multiple chains via DeFi composability, and the governance questions raised by Arbitrum's forced state transition to recover stolen funds.

On April 18, 2026, KelpDAO's rsETH LayerZero OFT bridge was exploited for approximately $290M in an attack attributed to a state-sponsored actor, likely DPRK's Lazarus Group [1]. The root cause was KelpDAO's 1-of-1 DVN configuration, which reduced cross-chain message verification to a single point of failure. The attacker poisoned the RPC infrastructure trusted by the LayerZero Labs DVN, forcing it to attest a fabricated cross-chain message that caused 116,500 rsETH to be released on Ethereum without any corresponding source-side event on Unichain.

Background

LayerZero is a cross-chain messaging protocol built on a modular security architecture. At its core, cross-chain message integrity is enforced by Decentralized Verifier Networks (DVNs), off-chain entities responsible for independently verifying that a message sent on a source chain actually occurred before it is executed on the destination chain. Each application deploying on LayerZero configures its own DVN setup, including which DVNs to trust, how many are required, and what consensus threshold must be met. This modularity gives applications full control over their security model, but also full responsibility: a weak configuration cannot be backstopped by the protocol itself.

KelpDAO's rsETH is deployed as an OFT (Omnichain Fungible Token) on LayerZero, with a bridge route connecting Unichain (source) and Ethereum mainnet (destination). The OFT standard allows tokens to be burned on the source chain and released from a lock on the destination chain, with the cross-chain message serving as the sole authorization for the release. The Ethereum-side adapter (0x85d456...e98ef3) is responsible for releasing rsETH to recipients once a valid cross-chain message has been verified and delivered. Critically, KelpDAO configured this pathway with a 1-of-1 DVN setup, designating LayerZero Labs as the sole verifier. This means a single DVN attestation was sufficient to authorize any token release, with no second opinion required.

To perform its verification duties, the LayerZero Labs DVN queries multiple RPC nodes to confirm that a cross-chain send event actually occurred on the source chain. These RPC nodes include both self-operated infrastructure and external providers, and the DVN relies on their collective responses before signing an attestation. The integrity of this process depends on the assumption that a majority of queried nodes return truthful data.

Vulnerability Analysis

The vulnerability is a systemic failure at the infrastructure and configuration level, composed of three compounding weaknesses.

First, KelpDAO's 1-of-1 DVN configuration eliminated all redundancy in the verification layer. LayerZero's recommended security posture explicitly requires multi-DVN setups with independent verifiers, such that no single DVN can unilaterally authorize a message. By relying solely on the LayerZero Labs DVN, KelpDAO ensured that any compromise of that single verifier would be sufficient to authorize an arbitrary token release.

Second, the DVN's failover mechanism routes verification queries to whichever RPC nodes remain reachable. This design assumes node unavailability is accidental rather than deliberate. However, it creates a condition where an attacker does not need to compromise all data sources: by taking the healthy nodes offline via DDoS and having poisoned nodes ready as the only reachable alternative, the attacker can gain full control over the data the DVN receives.

Third, replacing the op-geth executable on the RPC nodes required OS-level access to the underlying servers. The exact initial access vector was not disclosed, but compromising two independent nodes on separate clusters may indicate a shared weakness in how access to these servers was controlled.

Together, these three conditions formed a complete attack chain: the first ensured there was no independent DVN to cross-check the attested message, the second ensured the attacker could fully control the data the sole DVN received, and the third provided the initial foothold that made the data manipulation possible. No single weakness alone would have been sufficient. Without the 1-of-1 configuration, a second DVN querying independent infrastructure would have rejected the forged message. Without the failover behavior, the healthy nodes would have outvoted the poisoned ones. Without the server compromise, the attacker would have had no way to inject forged data in the first place.

Attack Analysis

The following analysis is based on the transaction 0x1ae232...4222 and the official incident statement by LayerZero Labs.

• Step 1: The attacker obtained the list of specific RPC nodes trusted by the LayerZero Labs DVN. This list constituted a high-value intelligence target, because knowing the exact nodes allowed the attacker to plan a surgical operation rather than a broad infrastructure attack.

• Step 2: The attacker gained OS-level write access to two of the RPC nodes and replaced the running op-geth binaries with malicious versions. These two nodes were described as running on independent clusters with no direct connection to each other, suggesting the initial access vector involved a shared upstream dependency (e.g., compromised deployment credentials, a CI/CD pipeline, or social engineering of an operator with access to both). The exact initial access method was not disclosed by LayerZero Labs. This step was the prerequisite for all subsequent data manipulation.

• Step 3: The malicious op-geth binary implemented targeted response logic: it returned forged transaction data exclusively to the DVN's IP address, while serving truthful blockchain state to all other requesters, including LayerZero's own monitoring infrastructure, block explorers, and scan services. This selective poisoning made the attack invisible to all existing observability systems; from every external perspective, the source chain appeared normal.

• Step 4: The DVN's internal consensus required agreement across both poisoned and uncompromised RPC nodes. To resolve this conflict, the attacker DDoS'd the remaining healthy nodes during the attack window (10:20 to 11:40 AM PT), triggering the DVN's failover logic and forcing it to rely exclusively on the poisoned infrastructure. This step was necessary because the healthy nodes would otherwise have returned truthful data that contradicted the forged responses.

• Step 5: With the DVN now receiving only attacker-controlled data, a fabricated LayerZero cross-chain message was presented as valid. The DVN attested nonce 308 on the Ethereum destination endpoint, a nonce that had no corresponding outbound event on Unichain (confirmed by the source endpoint still reporting a maximum outbound nonce of 307).

• Step 6: The Ethereum-side rsETH adapter, receiving a validly attested message, released 116,500 rsETH to the attacker's recipient address (0x8b1b6c...0d3b), which had been pre-funded via Tornado Cash hours earlier. The stolen tokens were immediately dispersed across seven branch wallets and liquidated through Aave collateral positions, direct ETH swaps, and re-bridging to Arbitrum, with final proceeds consolidating at 0x5d3919...7ccc on Ethereum and a corresponding collector on Arbitrum.

• Step 7: The malicious binary executed a self-destruct routine upon completion, deleting itself along with all local logs and configuration files. This significantly impeded post-incident forensic recovery and illustrates the attacker's operational sophistication.

• Step 8: A subsequent attempt by the attacker to exploit the same pathway for an additional 40,000 rsETH (~$95M) was blocked after KelpDAO detected the anomaly and paused all relevant contracts on Ethereum mainnet and L2s [2].

Broader Impact

The damage extended well beyond the initial $290M bridge exploit. The attacker deposited approximately 89,567 rsETH (~$221M) into Aave across multiple markets, borrowing WETH at E-Mode's 93% LTV [4]. Because Aave could not distinguish legitimately bridged rsETH from tokens released via a forged message, the "poisoned" collateral was treated as fully valid. The resulting WETH reserve freeze propagated across Ethereum, Arbitrum, Base, Mantle, and Linea, affecting users who had no exposure to rsETH whatsoever. This cascading propagation, from a single bridge configuration flaw to multi-chain lending market disruption, illustrates how DeFi composability amplifies both the reach and the cost of a single point of failure.

The aftermath raised equally important questions about the operational reality of decentralization. LayerZero Labs announced that its DVN will no longer sign messages for applications using 1-of-1 configurations [1], implying that protocol-level decentralization alone cannot compensate for application-level configuration weaknesses.

On the chain level, the Arbitrum Security Council executed an emergency action to freeze 30,766 ETH held by the attacker on Arbitrum One. As analyzed by BlockSec [5], this was accomplished via a chain-level forced state transition: the Security Council temporarily upgraded the Ethereum inbox contract, injected an unsigned L1-to-L2 message impersonating the attacker's address, and restored the original implementation, all without requiring the holder's signature [3].

This action was a legitimate exercise of governance-defined emergency powers, conducted transparently and in coordination with law enforcement. Yet it also demonstrates that L2 chains retain centralized intervention capabilities by design: any asset on Arbitrum One can, in principle, be moved by the Security Council through the same mechanism. The gap between a system's theoretical trust model and its actual trust boundary is, as this incident shows at every layer, where the most consequential risks reside.

Conclusion

This incident demonstrates that bridge security cannot be reduced to protocol correctness alone. The LayerZero protocol itself functioned as designed; the vulnerability existed entirely in the operational layer above it. The core lesson is that off-chain verification infrastructure is part of the trust boundary, and its security posture must match the value it protects.

Three mitigations would have individually prevented this outcome:

• Multi-DVN configuration: Requiring consensus across multiple independent DVNs would have rendered a single DVN compromise insufficient to authorize a message, regardless of how completely that DVN was deceived.

• Failover-aware RPC selection: A sudden drop in reachable nodes during an active verification window should be treated as a potential attack signal rather than a routine availability event. DVN implementations should halt or alert instead of proceeding with a reduced node set.

• RPC infrastructure hardening: The ability to replace a running executable on a production RPC node indicates insufficient access controls on the underlying servers. Infrastructure that DVNs depend on for source-chain ground truth should be subject to the same security boundary as the DVN signing instances themselves.

More broadly, any bridge or cross-chain protocol that relies on off-chain attestation should audit not just the smart contract layer, but the full data pipeline from source-chain event to destination-chain execution. The assumption that RPC infrastructure is trustworthy by default is no longer tenable when hundreds of millions of dollars depend on it.

References

[1] LayerZero Labs, "KelpDAO Incident Statement," April 20, 2026. https://x.com/LayerZero_Core/status/2046081551574983137

[2] KelpDAO, "April 18 Incident: Additional Context," April 21, 2026. https://x.com/KelpDAO/status/2046332070277091807

[3] Arbitrum, "Security Council Emergency Action," April 21, 2026. https://x.com/arbitrum/status/2046435443680346189

[4] LlamaRisk, "rsETH Incident Report," April 20, 2026. https://governance.aave.com/t/rseth-incident-report-april-20-2026/24580

[5] BlockSec, "Arbitrum Security Council Freeze Mechanism Analysis," April 21, 2026. https://x.com/Phalcon_xyz/status/2046467830498173088

More Incidents This Week

Rhea Finance

On April 16, 2026, Burrowland, a lending and margin-trading protocol on NEAR under Rhea Finance, was exploited for approximately $18.4M due to a business-logic flaw in its margin-trading module. When opening a leveraged position, the protocol relies on verify_token_out() to validate the expected swap output before accepting the position. However, this function incorrectly accumulated token_out amounts from intermediate swap steps whenever the token matched the final output token, failing to account for the fact that these intermediate amounts were subsequently reused as token_in. The attacker deployed fake tokens and pools, then constructed a circular swap path that inflated the perceived output amount and passed solvency checks, draining approximately $18.4M from the protocol.

Background

Burrowland is an open-source lending and margin-trading protocol on NEAR. In addition to standard supply and borrow functionality, it supports margin trading and introduces three key variables to represent a user's leveraged position: token_c (collateral), token_d (debt asset), and token_p (position asset).

For a long position, the user deposits token_c as collateral and borrows token_d at a chosen leverage (e.g., 5x). The borrowed token_d is then swapped on a DEX into token_p, the asset the user wants exposure to. Under normal conditions, the value of token_p received is approximately equal to the value of token_d spent. The protocol holds token_p on behalf of the user, while recording the borrowed token_d as debt.

For a short position, the user similarly deposits token_c and borrows token_d (the asset they want to short) with leverage. The borrowed token_d is swapped into another asset (token_p), effectively taking a short exposure to token_d. Again, the swap is expected to preserve value under normal market conditions.

Throughout the position's lifecycle, token_p remains custodied within the protocol and the user cannot directly withdraw it. The position must be closed to realize profit or loss, at which point token_p is swapped back into token_d to repay the debt.

Opening a margin position is handled by internal_margin_open_position(), which sets up the position parameters and dispatches the borrow to the DEX.

Before the protocol accepts a new position, it evaluates four protections in sequence: is_min_amount_out_reasonable() cross-checks the user-declared min_token_p_amount against the Pyth-oracle-implied swap output to cap slippage, is_open_position_liquidatable() verifies that the expected position-and-collateral value clears the liquidation line, is_open_position_forcecloseable() verifies that the account is not already insolvent on paper, and get_open_position_lr() enforces that token_d / token_c value does not exceed the maximum leverage rate.

All four checks use min_token_p_amount as the value of the position asset, because the swap has not yet executed and there is no realized amount to use. The correctness of every gate therefore hinges on min_token_p_amount being bound to what the DEX will actually deliver. That binding is exactly what verify_token_out(), implemented via RefV1TokenReceiverMessage::get_token_out(), is supposed to enforce on the swap message the user submits.

Vulnerability Analysis

The flaw is inside verify_token_out(). The function picks the last swap step's token_out as the final output token, then sums the declared min_amount_out of every swap step that produces the same token, on the assumption that each such production contributes to the final output. This is correct for a genuine multi-path (split-route) swap, but it does not exclude steps whose token_out is immediately consumed as the next step's token_in. A round-trip path such as A->B->A->B causes every ->B step to be counted toward the sum even though its output is spent in the following B->A step and never reaches Burrowland. The summed min_amount_out that verify_token_out() approves no longer represents what the DEX will actually return.

Once verify_token_out() is bypassed, the inflated min_token_p_amount is treated as ground truth throughout internal_margin_open_position(). Every solvency gate that was meant to stop an unsafe open computes against a fabricated number, so the position is accepted and the protocol dispatches the borrowed token_d to the DEX with the circular swap message attached.

Attack Analysis

The following analysis is based on the transaction GcXEKm...fnFT.

Phase 1: Fake Token and Pool Deployment

The attacker deployed three fake tokens and created five fake pools.

1. Fake Token IDs:

   1. Fake1: 31623e1d98275d2b0db4f50e102f6bf40877c1345e06e4ca6727f58c89564bb2

   2. Fake2: 6a28e3d3c7af1415ec22c6264013e1138bab00f85b8b6055d882d7d46afdf49b

   3. Fake3: e081e03daf58f5bb04cf95a03017e58449b76e704f1974771d7e3bd52835b6e5

2. Fake Pool IDs:

   1. Zec-Fake1: 7509

   2. Fake1-Fake2: 7510

   3. USDC-Fake2: 7511

   4. Fake2-Fake3: 7512

   5. Fake3-USDC: 7513

Phase 2: Margin Position Opening

• Step 1: Using Burrowland's margin-trading feature, the attacker opened a leveraged position with a legitimately valuable asset as token_c and a real reserve asset as token_d, attaching a swap message whose action list is a round-trip A->B->A->B routed entirely through the attacker-controlled pools from Phase 1.

• Step 2: Because verify_token_out() sums min_amount_out across every step whose token_out matches the terminal output, the round-trip path let the attacker inflate the declared min_token_p_amount to an arbitrary value.

• Step 3: The inflated min_token_p_amount passed every open-time health check in internal_margin_open_position(), so the position was accepted and the protocol dispatched token_d to Ref-Finance.

• Step 4: The circular swap returned only a dust amount of token_p; on_open_trade_return() booked it without any re-check, leaving the position insolvent from creation.

• Step 5: The borrowed token_d settled inside the attacker-controlled pools along the path; the attacker extracted it via remove_liquidity().

• Step 6: Because the borrow is leveraged, the withdrawn token_d is worth more than the posted token_c. The gap is net profit per cycle, and the uncollectible debt is forceclosed into protocol_debts. The attacker repeated the construction until roughly $18.4M had been drained.

Conclusion

This incident was caused by a business-logic flaw in Burrowland's margin-open path. The function RefV1TokenReceiverMessage::get_token_out() incorrectly aggregated intermediate outputs whenever they matched the final token, assuming these amounts would remain as final output. However, circular swap paths break this assumption, as these tokens can be reused and consumed within the path. As a result, the computed min_token_p_amount can be artificially inflated, causing all subsequent solvency checks to rely on an incorrect value and allowing positions to be opened against a fabricated health state without validating the actual received amount.

For production margin-trading contracts, developers should:

• Treat user-declared min_amount_out as unverified input, and either take only the final hop's min_amount_out or explicitly reject swap paths that re-consume a previously produced token_out (no cycles through the target).

• Bound declared slippage with both a lower and an upper envelope against the oracle-implied swap output, so that an attacker cannot unilaterally inflate the declared value to bypass solvency predicates.

Hyperbridge

On April 13, 2026, Hyperbridge, a cross-chain messaging bridge on Ethereum, was exploited for approximately $242K due to missing input validation in the MMR (Merkle Mountain Range) proof verification logic. The function MerkleMountainRange.VerifyProof() did not enforce that leaf_index < leafCount, allowing the attacker to forge a cross-chain proof and perform privileged actions including minting 1,000,000,000 DOT tokens.

Background

Hyperbridge uses an Ethereum-side verifier and dispatcher model for cross-chain messages. On Ethereum, the contract HandlerV1 validates the provided proofs against the stored overlayRoot, and if the proof is accepted, it dispatches the message to destination modules such as the contract TokenGateway.

The contract TokenGateway is a privileged asset-management module. Besides normal asset bridging, it also supports governance-style actions such as asset creation, deregistration, and admin management. For bridged assets implemented as ERC6160Ext20, the admin can directly transfer minting authority by calling the function changeAdmin(), and the new admin can then mint arbitrary supply via the function mint().

This means the safety of the whole asset bridge depends on the correctness of the proof verification path in HandlerV1. If a forged message can pass verification, downstream modules will treat attacker-controlled payloads as authentic cross-chain instructions.

Vulnerability Analysis

The core issue sits in the MMR proof verification flow in the contract HandlerV1 (0x6c84ed...6d64). The entry function handlePostRequests() first builds MmrLeaf(leaf.kIndex, leaf.index, commitment) based on the attacker-supplied inputs. Then, MerkleMountainRange.VerifyProof() is invoked to perform the proof validation.

MerkleMountainRange.VerifyProof(root, request.proof.multiproof, leaves, request.proof.leafCount)

However, VerifyProof() only checks whether root == CalculateRoot(proof, leaves, mmrSize) and does not validate that each leaf.index is within range (i.e., leaf.index < leafCount). By choosing leafCount = 1 and leaf_index = 1, the attacker causes CalculateRoot() to skip folding the forged request commitment into the computed root, returning the peak root directly. This breaks the message-to-proof binding and lets arbitrary payloads pass as valid against a historical overlayRoot.

Attack Analysis

The following analysis is based on the transaction 0x240aeb...1109 [1].

• Step 1: The attacker EOA 0xC513...F8E7 deployed helper contracts 0x518A...8f26 and 0x31a1...ca9AB in the same transaction.

• Step 2: The helper contract 0x31a1...ca9AB submitted a forged request via the vulnerable verification path in HandlerV1. Since VerifyProof() did not reject the out-of-bounds leaf_index, the forged request commitment was omitted from root calculation, yet the proof still matched a historical overlayRoot.

• Step 3: After the forged message was accepted, HandlerV1 dispatched it to TokenGateway, executing the ChangeAssetAdmin action. This changed the admin of the DOT token to the attacker-controlled helper contract 0x31a1...ca9AB.

• Step 4: The helper contract minted 1,000,000,000e18 DOT tokens.

• Step 5: The helper contract swapped the newly minted DOT tokens for 108.2 ETH via Odos Router V3.

• Step 6: The attacker transferred 108.2 ETH to its EOA account.

Conclusion

This incident was caused by improper proof validation in Hyperbridge's MMR verification logic. Since leaf_index < leafCount was not enforced, the attacker could forge a message whose commitment was never actually included in the computed root, yet still pass verification against a historical state root. Mitigations should enforce strict bounds checks such as leaf_index < leafCount before proof verification.

References

[1] BlockSec, "Hyperbridge Attack Analysis," April 13, 2026. https://x.com/Phalcon_xyz/status/2043601549893738970

Dango

On April 13, 2026, Dango, a perpetual futures DEX built as a Cosmos AppChain, was exploited for approximately $1.5M due to a missing sign check. The function replenish_insurance_fund() used is_non_zero() instead of is_positive() to validate the input amount, allowing the attacker to provide a negative UsdValue and drain the insurance fund into their margin position.

Background

Dango is a perpetual futures DEX built as a Cosmos AppChain. Users deposit USDC as collateral into the perps contract and open leveraged long or short positions on assets such as BTC, ETH, and SOL through an on-chain Central Limit Order Book (CLOB). Each user's collateral balance is tracked as a margin account within the perps contract.

To protect liquidity providers (LPs) from bad debt losses, the protocol maintains an insurance fund: a reserve of USDC held inside the perps contract that covers any shortfall when a liquidated position's collateral is insufficient to fully repay its debt. Without it, such shortfalls would be socialized directly onto LPs. Any user could contribute margin from their perp account to the insurance fund.

Vulnerability Analysis

The root cause lies in the function replenish_insurance_fund() of the contract 0x90bc84...bea4f, which fails to reject negative input amounts. The function has two guards, but neither stops a negative amount:

1. ensure!(amount.is_non_zero()) checks that the amount is not zero, but does not check that it is positive.
2. ensure!(user_state.margin >= amount) checks that the user has sufficient margin, but any positive margin satisfies >= negative_number.

With both guards passed, the function executes user_state.margin.checked_sub_assign(amount) and state.insurance_fund.checked_add_assign(amount). When amount is negative, subtracting it increases the user's margin, and adding it decreases the insurance fund, reversing the intended fund flow entirely.

Attack Analysis

Transactions:

Phase 1:

In Tx 1, the attacker performed the following steps to drain assets from Dango's insurance fund:

• Step 1: The attacker opened a margin position by depositing 1e6 USDC. This was a prerequisite for invoking replenish_insurance_fund().

• Step 2: The attacker invoked replenish_insurance_fund() with a negative amount (i.e., -1500000). Due to the improper validation, the negative amount was accepted, draining assets from the insurance fund to the attacker's margin position.

• Step 3: The attacker withdrew all assets from the margin position, gaining $1,500,000 of USDC.

Phase 2:

In Tx 2-8, the attacker invoked transfer_remote() to bridge stolen assets to Ethereum. As a result, $410,000 of USDC was bridged to Ethereum.

Conclusion

The essence of this attack is a signed integer type used in an unsigned context without a sign guard. The UsdValue type is signed by design (perps PnL can be negative), but the insurance fund donation pathway only makes sense for positive contributions. Using is_non_zero() instead of is_positive() left a one-word gap that allowed any caller to flip the direction of the fund flow, draining USDC from the insurance fund into their own margin. The attacker executed the entire attack in a single transaction (deposit $1, drain $1.5M, withdraw $1,500,001) and then slowly bridged funds out. The bridge rate limit was the only mechanism that limited the damage: without it, the entire ~$1.5M would have been irretrievably bridged to Ethereum.

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