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.

你可能也喜歡

通过掷骰子离线保管比特币密钥:并非人人愿意为之

文章探讨了通过投掷骰子生成比特币钱包种子短语的安全方法及其现实挑战。核心观点如下: **1. 骰子提供物理熵源** 骰子结果由众多微小变量决定,理论上虽可预测,但实践中无法被攻击者复制或计算,从而提供高质量的随机性。每个六面骰子投掷约产生2.585比特熵,50次投掷即可满足典型12词助记词(128比特熵)的安全需求。 **2. Coldcard漏洞事件凸显手工熵源的价值** 近期Coldcard硬件钱包因固件漏洞导致其内部随机数生成器存在缺陷,致使约1128枚比特币被盗。但那些**完全**通过足量骰子投掷生成种子短语的用户未受此漏洞影响,因为他们的主密钥未使用有缺陷的生成器。 **3. 重要警示:手工种子并非万能保护** 安全研究员指出,即使用户使用骰子生成了安全的种子,若他们使用了Coldcard的其他功能(如生成纸钱包、克隆密钥、共享签名密钥、密码等),这些**衍生密钥**仍可能调用有漏洞的随机数生成器,从而存在风险。安全种子不保证设备生成的所有秘密都安全。 **4. 手工生成熵源的现实局限性** 尽管数学上可靠,但该方法对大多数用户并不友好: * **过程繁琐易错**:需投掷50-99次,精确记录,任何输入错误都会导致钱包完全不同。 * **引入新风险**:用户可能在记录、转换过程中泄露信息,或使用有偏的骰子/投掷方式。 * **用户体验差**:难以想象大规模推广需要用户手动投掷近百次骰子。安全措施需适应现实生活场景和普通用户的知识水平。 **5. 给用户的建议** 受影响的Coldcard用户应: * 更新固件至最新版。 * 检查是否使用过有漏洞的功能生成了次级密钥或密码,如有则需立即更换。 * 考虑采用多签方案,使用不同厂商的设备分散风险。 **结论**:手工投掷骰子生成熵源是技术娴熟用户的一个有效安全选项,但其过程复杂、容易出错,不适合作为主流用户的默认方法。长远目标是依赖安全、透明且无需专业知识的硬件/软件随机数生成方案。

cryptonews.ru27 分鐘前

通过掷骰子离线保管比特币密钥:并非人人愿意为之

cryptonews.ru27 分鐘前

交易

現貨
活动图片