$292M Gone: Kelp DAO rsETH Cross-Chain Security Incident — Full Technical Analysis

Originally authored by BitsLab — a security research firm specializing in Web3 smart contract audits and on-chain forensics. Republished on BlockAINews with permission.

In DeFi, catastrophic losses rarely come from sophisticated zero-days. More often, they come from one number being set wrong.

On April 18, 2026, the rsETH cross-chain bridge operated by Kelp DAO / KernelDAO suffered a major security incident. The attacker exploited the LayerZero message-receiving pipeline to trigger an unauthorized release of canonical rsETH on Ethereum mainnet, then immediately deposited the stolen assets into lending protocols as collateral to borrow real ETH/WETH — transforming a bridge exploit into a multi-protocol liquidity crisis.

Estimated impact: ~116,500 rsETH, approximately $292M at the time of the attack.

I. Incident Overview

Based on public information and on-chain forensics, the core finding of this report is:

The high-value inbound bridge channel directly involved in this attack was explicitly configured on-chain as a 1-of-1 DVN security stack.

This means only one required DVN completing verification was sufficient to satisfy the message execution condition on the receiving side — a threshold clearly too low for a channel capable of releasing canonical rsETH reserves on Ethereum mainnet.

As of the latest public update on 2026-04-20, LayerZero's public statement and mainstream media coverage have further converged the root cause to:

The attacker poisoned the downstream RPC infrastructure relied upon by the LayerZero Labs DVN, while simultaneously DDoSing the remaining clean nodes — inducing the DVN to accept a forged cross-chain message during the failover window. Kelp's 1-of-1 DVN configuration allowed this forged message to pass through the high-value receiving path with no independent second verifier.

Current confidence levels:

• ✅ Single DVN configuration — directly confirmed by on-chain evidence
• ✅ Poisoned RPC nodes + DDoS + forged packet — consistently supported by LayerZero's latest public statement and media coverage
• ⚠️ Lazarus Group attribution — should be stated as "preliminary / likely," not a legally definitive conclusion
• ⚠️ Early speculation about source-chain OApp key compromise / admin role abuse — better retained as an early market hypothesis, no longer the primary root cause

II. Summary of Findings

From an audit and on-chain forensics perspective, this incident cannot be simply categorized as "a standard bug in a bridge contract function." A more accurate characterization is:

A security architecture failure caused by misconfigured cross-chain security settings at the application layer.

High-confidence confirmed facts include:

1. The primary attack transaction was executed via the LayerZero EndpointV2 message-receiving path
2. The effective configuration of ReceiveUln302 for the bridge channel was: requiredDVNCount = 1, optionalDVNCount = 0, optionalDVNThreshold = 0
3. This configuration was not derived from defaults — it was an explicit application-level config written via a setConfig call
4. Sole required DVN: 0x589dEDbD617e0CBcB916A9223F4d1300c294236b

The primary root cause is therefore defined as:

The high-value bridge channel operated with an insufficiently low DVN verification threshold, such that the compromise of a single verification domain was sufficient to escalate into a system-wide asset release event.

The more complete formulation: RPC infrastructure poisoning + DDoS of clean nodes provided the window for the malicious payload to be accepted, while the single DVN configuration provided the catastrophic amplification condition.

III. Affected Components

IV. Key Transactions

1. Primary Attack Transaction

• Hash: 0x1ae232da212c45f35c1525f851e4c41d529bf18af862d9ce9fd40bf709db4222
• Time: 2026-04-18 17:35:35 UTC
• Link: https://etherscan.io/tx/0x1ae232da212c45f35c1525f851e4c41d529bf18af862d9ce9fd40bf709db4222

This transaction was sent directly to the LayerZero EndpointV2. Input data shows srcEid = 0x7670 = 30320, with the receiving path linked to Kelp / Kernel's bridge OApp. This confirms the attack entry point was the cross-chain message receiving pipeline, not a direct call to a standard business function of the bridge OApp.

2. Explicit Configuration Transaction

• Hash: 0x2d48d9331d96c46f8b4a9f7a7bdcf256d2034dadb42f039d27dc28077d520592
• Time: 2025-04-02 08:14:47 UTC
• Link: https://etherscan.io/tx/0x2d48d9331d96c46f8b4a9f7a7bdcf256d2034dadb42f039d27dc28077d520592

This transaction set the receiving-side ULN config for bridge OApp 0x85d456...8ef3 on eid = 30320:

confirmations         = 42
requiredDVNCount      = 1
optionalDVNCount      = 0
optionalDVNThreshold  = 0
requiredDVNs          = [0x589d...236b]

The transaction receipt explicitly includes a UlnConfigSet log emitted by ReceiveUln302.

V. Timeline

January 2025 — Community Warning

External researchers reportedly warned that single-DVN configurations on certain Kelp / Kernel LayerZero channels posed serious risks, identifying it as an unsafe pattern for high-value bridged assets. The warning appears to have gone unaddressed.

If confirmed in a subsequent official post-mortem, this means this was not an unknown or unforeseeable problem — it was a known high-risk architectural configuration that had been flagged externally but not sufficiently remediated, with significant implications for accountability and security governance maturity.

2025-04-02

The receiving-side config for bridge OApp on srcEid = 30320 was explicitly set to single-DVN mode (1-of-1).

2026-04-18, 17:35:35 UTC

The attacker executed the primary attack transaction, triggering an asset release via the LayerZero receiving-side execution path.

Shortly After the Attack

The attacker distributed the obtained rsETH across multiple addresses and deposited them as collateral into Aave, Compound, Fluid, and Euler, borrowing real ETH/WETH against them. The verification failure at the bridge layer propagated into DeFi lending systems, triggering market freezes, lending parameter adjustments, and potential bad debt exposure.

2026-04-20 — Official Investigation Update

As of the morning of April 20, 2026, LayerZero publicly stated:

• Early indicators point to a highly sophisticated nation-state threat actor — likely DPRK's Lazarus Group
• The attacker poisoned downstream RPC infrastructure used by the LayerZero Labs DVN
• The attacker simultaneously DDoSed the remaining clean nodes, forcing the DVN to rely on compromised RPCs during failover
• This caused the DVN to confirm a cross-chain message that had not actually occurred
• Due to Kelp's 1-of-1 DVN configuration, there was no independent second verifier to intercept the forged message

This update significantly improves clarity on the attack mechanics and anchors the root cause more concretely to an infrastructure-level attack surface.

VI. On-Chain Technical Findings

1. Attack Path Confirmed as LayerZero Receiving Pipeline

The primary attack transaction targeted LayerZero EndpointV2, not any standard business interface of the bridge OApp. Combined with srcEid = 30320 in the input parameters, this confirms the attack core occurred within the cross-chain message receiving and execution flow.

2. Effective Verification Threshold: 1-of-1

On-chain reads of ReceiveUln302 show getAppUlnConfig and getUlnConfig returning consistent values:

requiredDVNCount     = 1
optionalDVNCount     = 0
optionalDVNThreshold = 0
requiredDVNs         = [0x589d...236b]

The path relied on a single required DVN, with no optional DVNs providing any fallback.

3. This Insecure Configuration Was an Explicit Application-Level Write

This high-value bridge channel was actively configured to operate under a single verification domain.

This 1-of-1 was not inferred from ambiguous defaults. It was written directly into the application path via a configuration transaction. This is the most important on-chain evidence in this root cause determination.

4. Public Investigation Has Converged on "RPC Poisoning + DDoS + Single DVN Passthrough"

The consolidated attack chain:

1. The attacker identified the downstream RPC node list used by the LayerZero Labs DVN
2. Two of those downstream RPC nodes were poisoned, providing the DVN with a false view of on-chain state
3. The attacker simultaneously DDoSed the remaining clean RPC nodes to trigger a failover
4. During this window, the DVN accepted and confirmed a forged cross-chain message
5. Due to the 1-of-1 DVN configuration on the receiving side, there was no independent second verifier to detect and reject the forged message
6. The malicious message entered the execution path and triggered the release of canonical rsETH

Confidence summary:

VII. Attack Path Analysis

Based on available evidence, the most plausible technical attack sequence:

1. The attacker identified and targeted the downstream RPC infrastructure relied upon by the LayerZero Labs DVN
2. Certain RPC nodes were poisoned to return fabricated or incorrect on-chain state to the DVN
3. The attacker simultaneously DDoSed the remaining clean RPC nodes to create a failover window
4. During this window, the DVN confirmed a forged cross-chain message
5. Because the path was configured as 1-of-1 DVN, a single required DVN completing verification was sufficient for the message to reach the receiving-side execution condition
6. The LayerZero receiving flow proceeded, and the message was submitted and entered execution
7. The bridge / OFT adapter released canonical rsETH based on the "verified" message
8. The attacker deposited the rsETH as collateral into Aave, Compound, Fluid, Euler, and other lending protocols
9. The attacker then borrowed approximately $236M in WETH/ETH, converting the bridge-layer failure into a broader DeFi capital risk event

VIII. Root Cause Analysis

Primary Root Cause

The high-value receiving-side bridge channel operated with an insufficiently low DVN security threshold.

This channel was responsible for releasing canonical rsETH reserves on Ethereum mainnet, yet its verification requirements were: 1 required DVN, 0 optional DVNs.

This reduces the real security of the entire path to the security of a single DVN / single verification domain — a clearly mismatched architecture for a high-value bridge reserve.

Direct Trigger

Based on LayerZero's latest public disclosure, the direct trigger chain was:

• Downstream RPC nodes relied upon by the LayerZero Labs DVN were poisoned
• Clean nodes were DDoSed, creating a failover window
• The DVN accepted a forged cross-chain message during this window

Regardless of the exact trigger mechanism, the 1-of-1 path configuration significantly amplified the consequences.

Two-Layer Root Cause Model

Amplifying Factors

• No secondary validation at the bridge / adapter layer for high-value releases
• No per-message cap or rate limiting on the bridge release path
• No timelock or manual confirmation for above-threshold asset releases
• rsETH was immediately usable as DeFi collateral, enabling rapid risk propagation

IX. Risk Classification

X. Confirmed vs. Pending

✅ Confirmed

1. Primary attack transaction executed via LayerZero EndpointV2
2. srcEid of attack channel: 30320
3. Bridge OApp: 0x85d456...8ef3
4. Explicit receiving-side configuration exists on-chain, effective ULN config: 1-of-1
5. Sole required DVN: 0x589d...236b, written by an explicit on-chain transaction
6. LayerZero's latest public statement attributes the attack mechanism to poisoned downstream RPC infrastructure + DDoS + forged message

❓ Pending

1. Specific details of how the sole DVN accepted or allowed the malicious message to reach a verified state
2. Identity of the specific RPC nodes targeted, precise poisoning details, and DDoS specifics
3. Whether the Lazarus Group attribution will be further confirmed by official or law enforcement channels
4. Whether any additional peer, delegate, executor, or control-plane configuration issues were involved

XI. Security Recommendations

Immediate Actions

1. Audit all high-value bridge channels immediately — cease use of 1-of-1 DVN configurations
2. Conduct a full review of all existing send / receive ULN configs
3. Audit all permissions for delegate, peer, executor, and receive library changes
4. Establish real-time monitoring for UlnConfigSet, verify, commitVerification, and anomalous lzReceive events

Short-Term

1. Require multi-DVN heterogeneous verification on all high-value channels
2. Implement per-message caps on bridge release paths
3. Implement rate limits / daily caps on bridge release paths
4. Introduce guardian veto or timelock mechanisms for large-value releases

Long-Term

1. Redesign high-value reserve release paths to prevent single messages from directly accessing the full reserve
2. Implement tiered isolation between low-value channels and high-value reserve channels
3. Add a second layer of business-level risk control beyond "message verified"
4. Determine cross-chain security thresholds based on asset risk exposure, not channel availability

XII. Background & Supplementary Analysis

On Early Warnings

As early as January 2025, external parties had flagged that certain Kelp / Kernel LayerZero channels using single-DVN configurations posed serious risks — noting that such setups were unsafe for high-value bridged assets. This risk appears to have received insufficient attention.

If confirmed in a subsequent official report, the governance implications are significant: this was not an unknown or unforeseeable problem. It was a known high-risk configuration that was flagged externally and still not sufficiently remediated.

On the Current Investigation Status

Kelp's official investigation remains ongoing in collaboration with LayerZero, auditors, and multiple security firms. A full post-mortem has not yet been published.

However, on-chain data and external security analysis have now converged strongly around:

• Single DVN configuration
• RPC poisoning + DDoS
• Cross-chain message forgery / forged packet

While the final determination of responsibility and specific control-plane failure details await official disclosure, the technical consensus on the attack path is already well-established.

XIII. Final Conclusion

The core problem in the Kelp DAO / KernelDAO rsETH security incident is not simply that "the attacker successfully submitted a malicious message." It is that:

A cross-chain receiving channel capable of directly releasing high-value canonical reserves on Ethereum mainnet was explicitly configured to authorize message execution with a single DVN.

This means the failure of a single verification domain no longer constitutes a localized verification issue — it directly escalates into a systemic asset release event.

In audit terms, this incident is most accurately classified as:

Security Architecture Failure — not a conventional contract logic bug.

If subsequent official post-mortems further confirm additional details, the full characterization of this incident will be:

RPC infrastructure compromise / poisoning + single DVN threshold configuration + absence of defense-in-depth on high-value bridge paths = a systemic security failure caused by the compounding of all three.

XIV. References

• Primary attack transaction: etherscan.io
• Configuration transaction: etherscan.io
• Bridge OApp: etherscan.io
• DVN address: etherscan.io
• LayerZero Security Stack
• LayerZero DVN Overview
• LayerZero Solidity API
• LayerZero's incident statement
• LayerZero investigation summary — CoinLive

This report is authored by the BitsLab security research team, based on on-chain public data and publicly available information as of publication. Updates will follow once the official post-mortem is released.