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.

你可能也喜欢

SpaceX交易权限现已开放:WEEX上线SPCXON交易对

2026年6月,SpaceX完成了史上最大规模的IPO,但大量投资者因券商限制、开户障碍和地域壁垒而无法参与。加密货币交易所WEEX推出了解决方案SPCXON/USDT现货交易对。SPCXON是一种基于Ondo代币化股票框架构建的产品,旨在为美国以外的合格交易者提供追踪SpaceX经济收益的途径,以USDT结算,交易便捷,无传统券商门槛。 SpaceX IPO定价为135美元,首日收盘接近161美元,随后一度冲高至225美元,公司估值约1.75万亿美元。看涨理由基于星链收入增长、无可匹敌的发射频率以及星舰里程碑。看跌观点则认为,其估值已达营收的90-110倍,且存在流通股稀少和即将到来的内部持股解锁等风险。 需注意,SPCXON提供的是价格敞口,而非股票所有权,不包含投票权和直接股息。其价格可能相对净资产价值出现溢价或折价,交易者需关注价差。 WEEX平台整合了包括SpaceX、MicroStrategy和Micron在内的多种代币化股权产品,用户可在统一账户内交易加密货币和股权敞口。平台还提供高达400倍杠杆的加密货币期货交易。 WEEX成立于2018年,全球用户超过620万,提供超过1200个现货交易对,并设有1000 BTC保护基金。平台亦提供跟单交易和AI工具等功能。 免责声明:本文内容不构成投资建议。

TheNewsCrypto16小时前

SpaceX交易权限现已开放:WEEX上线SPCXON交易对

TheNewsCrypto16小时前

Gate 研究院:加密金融产品掀起“华尔街化”浪潮,是竞争还是融合?

2009年比特币的创世区块暗含对传统金融体系的批判,其理想是建立去中心化、去中介、去银行的点对点金融系统。然而十七年后,比特币现货ETF获批、贝莱德等巨头发行相关产品、CME推出受监管衍生品、RWA(真实世界资产)和代币化国债市场快速增长等现象,显示传统金融正系统性地介入加密资产的发行、定价、托管和分销环节,引发了加密市场是否“华尔街化”的讨论。 文章认为,这并非单方面的吞并,而是加密体系与传统金融的双向融合与互补。加密领域提供无许可开放性、24小时交易和可编程结算,但缺乏合规通道、机构级托管和主流分销网络;传统金融则拥有牌照、信任、资金和渠道,但受限于交易时间、跨境门槛和结算效率。双方正朝彼此的核心优势靠拢。 这种融合体现为两条路径:一是以Gate为代表的加密交易所,逐步从提供代币化美股、CFD差价合约,发展到接入真实股票、港股、韩股交易,成为连接加密账户与传统券商基础设施的前端入口;二是以Robinhood为代表的传统券商,通过收购加密交易所、推出股票代币和建设自有Layer 2,将加密资产和链上代币化产品整合进其平台。两者的共同目标是争夺下一代综合金融账户的入口,让用户在一个界面内交易多种资产。 同时,RWA和链上国债作为资产层的融合正在加速。尽管规模尚小,但代币化国债等产品为链上提供了低波动收益资产,并吸引JP摩根、贝莱德等传统机构参与,测试未来资本市场的底层结算方式。 最终,加密与华尔街并非谁征服谁,而是在共同塑造一个更高效、全球化的统一资本市场。用户未来或将在同一个账户中自由交易比特币、股票、ETF、链上国债等多种资产,体验无缝的跨资产配置。去中心化的理想仍在底层协议中延续,而在应用层,一个融合了双方优势的新金融形态正在形成。

marsbit17小时前

Gate 研究院:加密金融产品掀起“华尔街化”浪潮,是竞争还是融合?

marsbit17小时前

交易

现货
活动图片