The Code Was Fine, But It Was Still Hacked: What Is the 'DVN Configuration Vulnerability' Behind the Biggest Hack of 2026?

marsbit发布于2026-04-19更新于2026-04-19

文章摘要

Title: Code Was Secure, Yet $293M Stolen: The 2026 DVN Configuration Breach Explained On April 18, 2026, Kelp DAO’s restaking protocol was exploited, losing 116,500 rsETH (worth $293M at the time) due to a configuration flaw—not a smart contract vulnerability. The attacker used a forged cross-chain message to drain funds via LayerZero’s bridge, then dispersed the stolen rsETH across Aave V3, Compound V3, and Euler to borrow real assets, ultimately escaping with $236M in WETH. The root cause was a critical misconfiguration in Kelp’s LayerZero V2 setup: the protocol used a 1-of-1 Decentralized Verifier Network (DVN) threshold, meaning only one node approval was needed to validate cross-chain messages. The attacker compromised that single node, allowing unauthorized minting of rsETH on Ethereum. This configuration choice—permitted by LayerZero but highly risky—left zero fault tolerance. In contrast, protocols like ApeChain using multi-node validation (e.g., 2-of-3 or 5-of-9) remained secure. This incident highlights a blind spot in DeFi security audits: tools like Slither and Mythril scan code for logic flaws but ignore configuration parameters. The 2022 Nomad hack ($190M loss) also stemmed from a config error, bringing total losses from such issues to ~$482M—rivaling private key breaches. The Kelp exploit underscores the need for standardized config audits and higher baseline security in cross-chain designs.

On April 18, 2026, attackers drained 116,500 rsETH, worth approximately $293 million at the time, from the cross-chain bridge of Kelp DAO's liquid restaking protocol within hours. The entire process was unusually efficient—from forging cross-chain messages to dispersing the stolen funds across three lending protocols, Aave V3, Compound V3, and Euler, to borrow real assets. The attackers exited the same day with $236 million in WETH. Aave, SparkLend, and Fluid promptly froze all rsETH markets.

This was the largest DeFi attack incident of 2026 to date.

But one thing set this attack apart from most hacking incidents. Kelp DAO's smart contract code had no vulnerabilities. Security researcher @0xQuit, who participated in the investigation, wrote on X, "From what I've gathered so far, this is the result of two issues叠加: a 1-of-1 DVN configuration and the DVN node itself being compromised." LayerZero's official statement also did not mention contract code, framing the issue as an "rsETH vulnerability" rather than a "LayerZero vulnerability."

$293 million, not found in a single line of code. It was hidden in a configuration parameter filled in incorrectly during deployment.

The general logic of DeFi security auditing is: find the contract, read the code, find the vulnerability. This logic works quite smoothly when dealing with code logic vulnerabilities; tools like Slither and Mythril have mature detection capabilities for known patterns like reentrancy attacks and integer overflows. LLM-assisted code auditing, heavily promoted in recent years, also has some capability against business logic vulnerabilities (such as flash loan arbitrage paths).

But two rows in this matrix are red.

Configuration-layer vulnerabilities are a structural blind spot in tool-based auditing. The problem with Kelp DAO was not in the .sol files, but in a parameter written during protocol deployment—the DVN threshold. This parameter determines how many validator nodes need to confirm a cross-chain message before it is deemed legitimate. It doesn't enter the code, doesn't enter Slither's scan range, and doesn't enter Mythril's symbolic execution path. According to comparative research by Dreamlab Technologies, Slither and Mythril detected 5/10 and 6/10 vulnerabilities in the tested contracts, respectively, but this achievement is based on the premise that "the vulnerability is in the code." According to IEEE research, even at the code level, existing tools can only detect 8%-20% of exploitable vulnerabilities.

From the perspective of current auditing paradigms, there is no tool that can "detect whether the DVN threshold is reasonable." To detect such configuration risks, what is needed is not a code analyzer, but a specialized configuration checklist: "Number of DVNs used by the cross-chain protocol ≥ N?", "Is there a minimum threshold requirement?" Such questions currently have no standardized tool coverage, nor even widely accepted industry standards.

Also in the red zone are key and node security. @0xQuit's description mentioned the DVN node being "compromised," which falls under operational security (OpSec), beyond the detection boundaries of any static analysis tool. Neither any first-tier auditing firm nor AI scanning tools have the ability to predict whether a node operator's private key will be leaked.

This attack triggered both red zones in the matrix simultaneously.

DVN is LayerZero V2's cross-chain message verification mechanism, short for Decentralized Verifier Network. Its design philosophy is to give security decision-making power to the application layer: each protocol integrated with LayerZero can choose how many DVN nodes need to confirm simultaneously before allowing a cross-chain message to pass.

This "freedom" creates a spectrum.

Kelp DAO chose the far left end of the spectrum: 1-of-1, requiring confirmation from only one DVN node. This meant a fault tolerance of zero; the attacker only needed to compromise that one node to forge any cross-chain message. In contrast, Apechain, also integrated with LayerZero, configured more than two required DVNs and was unaffected in this incident. LayerZero's official statement used the wording "all other applications remain secure," the subtext of which is: security depends on which configuration you chose.

The normal industry recommendation is at least 2-of-3, requiring an attacker to compromise two independent DVN nodes simultaneously to forge a message, increasing fault tolerance to 33%. High-security configurations like 5-of-9 can achieve 55% fault tolerance.

The problem is, external observers and users cannot see this configuration. Both might be called "powered by LayerZero," but behind it could be 0% fault tolerance or 55% fault tolerance. Both are called DVN in the documentation.

Veteran crypto investor Dovey Wan, who experienced the Anyswap incident, wrote directly on X: "LayerZero's DVN is actually 1/1 validator...... All cross-chain bridges should immediately conduct a comprehensive security review."

In August 2022, a vulnerability was discovered in the Nomad cross-chain bridge. Someone copied the first attack transaction, made slight modifications, found it also worked—so hundreds of addresses successively began copying, draining $190 million within hours.

Nomad's post-mortem wrote that the vulnerability source was "initializing the trusted root to 0x00 during a routine upgrade." This was a configuration error that occurred during the deployment phase. The Merkle proof verification logic was fine, the code itself was fine; the problem was an initial value filled in incorrectly.

This time, combined with Nomad, configuration/initialization class vulnerabilities have caused approximately $482 million in losses. In the entire history of cross-chain bridge thefts, this category's scale is now comparable to key leak class (Ronin $624 million, Harmony $100 million, Multichain $126 million, totaling approximately $850 million).

But the product design of the code auditing industry has never been targeted at this category.

The most discussed topics in the industry are still code logic vulnerabilities. Wormhole's $326 million hack due to signature verification bypass, Qubit Finance's $80 million theft due to fake deposit events. These cases have complete vulnerability analysis, CVE number analogies, reproducible PoCs, suitable for the training and optimization of auditing tools. Configuration-layer problems are not written in the code and struggle to enter this production cycle.

A noteworthy detail is that the triggering methods of the two configuration-class events were completely different. Nomad accidentally filled in a wrong initial value during a routine upgrade, a mistake. Kelp DAO's 1-of-1 was an active configuration choice—the LayerZero protocol did not prohibit this option, and Kelp DAO did not violate any protocol rules. A "compliant" configuration choice and a "mistaken" initial value ultimately led to the same consequence.

The execution logic of this attack was simple: a forged cross-chain message told the Ethereum mainnet that "equivalent assets have been locked on another chain," triggering the minting of rsETH on the mainnet. The minted rsETH itself had no actual backing, but its on-chain record was "legitimate" and could be accepted as collateral by lending protocols.

The attacker then dispersed the 116,500 rsETH into Aave V3 (Ethereum and Arbitrum), Compound V3, and Euler, borrowing over $236 million in real assets. According to multiple reports, Aave V3 alone faced an estimated bad debt of approximately $177 million. Aave's safety module, Umbrella, has a WETH reserve of about $50 million available to absorb bad debt, covering less than 30%, with the remaining portion to be borne by aWETH stakers.

This bill ultimately fell on those who just wanted to earn a little WETH interest.

LayerZero officials, as of writing, are still jointly investigating with the security emergency response organization SEAL Org, stating they will release a post-mortem report with Kelp DAO after obtaining all information. Kelp DAO stated it is conducting "active remediation."

The $293 million vulnerability was not in the code. The phrase "audit passed" did not cover the location of that parameter.

相关问答

QWhat was the root cause of the Kelp DAO hack in April 2026, and why was it unusual?

AThe root cause was a configuration vulnerability, specifically a 1-of-1 DVN (Decentralized Verifier Network) threshold setting chosen by Kelp DAO, combined with the compromise of that single DVN node. It was unusual because the smart contract code itself had no vulnerabilities; the flaw was entirely in a deployment configuration choice.

QWhat is a DVN in the context of LayerZero V2, and what security risk did Kelp DAO's configuration introduce?

AA DVN (Decentralized Verifier Network) is LayerZero V2's mechanism for verifying cross-chain messages. It allows applications to choose how many independent DVN nodes must confirm a message for it to be considered valid. Kelp DAO's configuration of a 1-of-1 threshold meant it had zero fault tolerance. An attacker only needed to compromise that one specific node to forge any cross-chain message, creating a critical single point of failure.

QHow do configuration vulnerabilities like the one at Kelp DAO differ from code logic vulnerabilities, and why are they hard to detect with standard auditing tools?

AConfiguration vulnerabilities exist in deployment parameters and initial settings (e.g., DVN threshold), not in the smart contract code itself. Standard auditing tools like Slither and Mythril are designed to scan .sol files for code logic flaws (e.g., reentrancy attacks) but are structurally blind to configuration choices made outside the code during deployment. There are no widely adopted standardized tools or industry norms for auditing these types of risks.

QWhat was the financial impact of the attack on the broader DeFi ecosystem, particularly on lending protocols?

AThe attacker stole 116,500 rsETH (worth ~$293M at the time) by forging a cross-chain message. They then used this unbacked rsETH as collateral to borrow over $236 million in real assets (WETH) from Aave V3, Compound V3, and Euler. Aave V3 faced an estimated $177 million in bad debt, which its safety module could not fully cover, meaning losses were ultimately borne by aWETH stakers.

QHow does the Kelp DAO incident compare to the 2022 Nomad hack, and what do they reveal about a growing category of DeFi risks?

ABoth the Kelp DAO (2026, $293M) and Nomad (2022, $190M) hacks were caused by configuration/initialization vulnerabilities, not code bugs. Together, they represent nearly $4.82 billion in losses from this category. This highlights a significant blind spot in DeFi security, as traditional code audits are not designed to catch misconfigurations or poor parameter choices made during protocol deployment, making them a major and growing risk class alongside key leaks and code exploits.

你可能也喜欢

单日暴跌 30%,海耶斯突然清仓,ZEC 为何被爆安全问题?

6月5日,Zcash创始人Zooko Wilcox等人披露其隐私层Orchard池存在关键健全性漏洞,攻击者可利用该漏洞在隐蔽环境下无限伪造ZEC。尽管项目方此前已紧急完成网络升级修复,但详细披露后ZEC价格剧烈波动,单日跌幅一度超30%,最低触及411美元附近。 此次漏洞源于Orchard电路中的椭圆曲线乘法约束不足,允许攻击者构造看似有效的交易,在隐私池内凭空生成ZEC。由于Orchard的隐私特性,链上无法区分真伪,导致池内用户资产可能被变相稀释。Zcash创始人坦言,密码学上无法证明修复前漏洞是否已被利用,此声明加剧了市场恐慌。 漏洞由安全研究员Taylor Hornby借助Anthropic最新AI模型Opus 4.8在针对性审查中发现,凸显了AI工具在安全审计中的强大能力,也意味着攻击者可能利用类似工具加速漏洞挖掘。Orchard自2022年激活以来历经多次审计仍存在缺陷,这对依赖复杂密码学实现的隐私项目敲响了警钟。 事件发生后,知名投资者Arthur Hayes宣布已清仓其全部ZEC持仓。此次事件直接挑战了隐私币“技术可信即核心价值”的叙事,促使行业重新审视隐私技术从理论到实践过程中的安全鸿沟。在AI驱动的攻防新常态下,依赖“未被发现即安全”的侥幸心理已不可行,持续主动的安全审查与快速响应机制变得至关重要。

foresightnews_api56分钟前

单日暴跌 30%,海耶斯突然清仓,ZEC 为何被爆安全问题?

foresightnews_api56分钟前

破除 DeFi 循环清算魔咒,Vitalik 提出了新方案

Vitalik Buterin 提出了一种新的 DeFi 设计思路,旨在解决传统抵押借贷协议中自动清算机制加剧市场波动的根本问题。其核心提议是:以期权为底层构建合成资产,从产品设计上彻底移除强制清算环节。 传统模式(如 Aave)中,一旦抵押品价格跌破预设阈值,仓位会被系统自动强制平仓。这在市场暴跌时容易引发集中抛售,放大下跌幅度,形成“清算-抛压-再清算”的恶性循环。 Vitalik 的新方案将 1 枚 ETH 拆分为两类关联的期权资产(P 和 N)。其价值总和始终等于 1 ETH,但各自相对于目标价格(如美元)的敞口会随着市场行情逐渐偏移,而不会发生瞬间的清算事件。风险从“断崖式平仓”转变为“渐进式价值偏离”,用户需要通过主动调仓(如轮换至不同行权价的期权)来管理风险,将再平衡的主动权交还给用户。 该设计还能降低对高频率、实时预言机报价的依赖,允许采用容错率更高、延迟结算的定价机制,减少因预言机异常或市场操纵引发的风险。 然而,该方案也存在待解挑战:用户需容忍资产价值的持续偏移与定期调仓的成本;依赖 AMM 进行频繁调仓可能产生高滑点;需要发展新的做市商模式提供流动性。它更适合作为对冲或指数追踪工具,而非要求严格锚定(如1美元)的会计结算型稳定币。 目前,该提案尚处于理论探讨阶段,但标志着行业顶尖思维开始质疑并寻求替代“强制清算”这一 DeFi 固有风控模式的可能性,为未来设计提供了新方向。

foresightnews_api59分钟前

破除 DeFi 循环清算魔咒,Vitalik 提出了新方案

foresightnews_api59分钟前

交易

现货
合约
活动图片