Even with no code issues, it was still stolen. What is the "DVN configuration vulnerability," the cause of the 2026 biggest hacking case?

Title: The Code Is Fine but Still Gets Hacked: What Is the “DVN Configuration Vulnerability” Behind the Largest Hack of 2026?

Author: 0x2333

Source:

Repost: Mars Finance

On April 18, 2026, Kelp DAO’s liquidity re-staking protocol was attacked within a few hours, with the attacker draining 116,500 rsETH from the cross-chain bridge, worth approximately $293 million at the time. The entire process was unusually efficient—from forging cross-chain messages to dispersing the stolen funds into real assets borrowed from Aave V3, Compound V3, and Euler—by the end of the day, the attacker had withdrawn $236 million worth of WETH. Aave, SparkLend, and Fluid subsequently froze the rsETH markets across the board.

This is the largest DeFi attack so far in 2026.

But one thing sets this attack apart from most hacking incidents. Kelp DAO’s smart contract code had no vulnerabilities. Security researcher @0xQuit, involved in the investigation, wrote on X: “Based on what I currently know, this is a combination of two issues: a 1-of-1 DVN configuration and the DVN nodes themselves being compromised.” LayerZero’s official statement also did not mention any contract code, classifying the issue as a “rsETH vulnerability” rather than a “LayerZero vulnerability.”

$293 million is not in any line of code. It’s hidden in a misconfigured parameter during deployment.

The general logic of DeFi security audits is: find the contract, read the code, identify vulnerabilities. This approach works quite well for logical bugs—tools like Slither and Mythril are mature at detecting known patterns such as reentrancy and integer overflow. Recently promoted LLM-assisted code audits also have some ability to identify business logic flaws (like flash loan arbitrage paths).

However, there are two critical areas where this matrix turns red.

Vulnerabilities at the configuration layer are a blind spot for automated tools. The problem with Kelp DAO was not in the .sol files but in a parameter set during protocol deployment—the DVN threshold. This parameter determines how many verification nodes must confirm a cross-chain message for it to be considered valid. It’s not part of the code, not within Slither’s scanning scope, nor in Mythril’s symbolic execution paths. According to a comparative study by Dreamlab Technologies, Slither and Mythril detect 5/10 and 6/10 vulnerabilities respectively in tested contracts, but only under the assumption that vulnerabilities are in the code. IEEE research shows that even at the code level, existing tools can only detect 8%-20% of exploitable vulnerabilities.

From the perspective of current audit paradigms, there are no tools capable of “detecting whether the DVN threshold is reasonable.” To assess such configuration risks, what’s needed isn’t a code analyzer but a dedicated configuration checklist: “Is the number of cross-chain verification nodes ≥ N?” “Is there a minimum threshold requirement?” Currently, no standardized tools or industry norms cover these questions.

Also in the red zone are key and node security. @0xQuit’s description mentions that the DVN nodes “were compromised,” which falls under operational security (OpSec)—beyond the reach of static analysis tools. No leading audit firm or AI scanning tool can predict whether a node operator’s private keys will be leaked.

This attack triggered two red areas in the matrix simultaneously.

DVN is LayerZero V2’s cross-chain message verification mechanism, short for Decentralized Verifier Network. Its design philosophy is to delegate security decision-making to the application layer: each protocol connected to LayerZero can choose how many DVN nodes must confirm a message before it’s accepted.

This “flexibility” creates a spectrum.

Kelp DAO chose the leftmost end of the spectrum—1-of-1—requiring only one DVN node to confirm. This means zero fault tolerance; an attacker only needs to compromise that one node to forge arbitrary cross-chain messages. In contrast, Apechain, which also uses LayerZero, configured more than two required DVNs, and was unaffected by this incident. LayerZero’s official statement said, “All other applications remain secure,” implying that security depends on your configuration choice.

Industry best practice recommends at least 2-of-3, meaning an attacker would need to compromise two independent DVN nodes simultaneously, raising 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 these configurations. The same “LayerZero-supported” label might hide a 0% fault tolerance or a 55% fault tolerance. Both are called DVN in the documentation.

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

In August 2022, Nomad’s cross-chain bridge was found to have a vulnerability. Someone copied the first attack transaction, made slight modifications, and successfully exploited it—leading hundreds of addresses to replicate the attack and drain $190 million within hours.

Nomad’s post-mortem analysis explained that the vulnerability stemmed from “initializing the trusted root to 0x00 during a routine upgrade.” This was a configuration error during deployment. The Merkle proof verification logic was correct, the code was sound, but an initial value was set incorrectly.

Together with Nomad, configuration/initialization vulnerabilities have caused losses of about $482 million. In the history of cross-chain bridge thefts, this category now rivals key leakage incidents (Ronin $624 million, Harmony $100 million, Multichain $126 million, totaling approximately $850 million).

However, the product design of the code audit industry has never targeted this category.

Most industry discussions focus on logical code vulnerabilities—cases like Wormhole’s $326 million theft due to signature verification bypass, or Qubit Finance’s $80 million theft from fake deposits. These incidents have comprehensive vulnerability reports, CVE identifiers, reproducible PoCs, and are suitable for training and optimizing audit tools. Configuration-layer issues, which are not embedded in code, are much harder to detect in the production cycle.

A notable detail is that the two configuration incidents were triggered in entirely different ways. Nomad’s was an accidental misconfiguration during a routine upgrade, while Kelp DAO’s 1-of-1 was a deliberate configuration choice—LayerZero protocol did not prohibit this option, and Kelp DAO did not violate any rules. Both “compliant” configuration choices and “mistaken” initial values ultimately led to the same outcome.

The attack’s execution was straightforward: a forged cross-chain message told the Ethereum mainnet, “Someone on the other chain has already locked the equivalent assets,” triggering the mainnet to mint rsETH. The minted rsETH had no actual endorsement, but its on-chain record was “legitimate,” and it was accepted as collateral by lending protocols.

The attacker then dispersed 116,500 rsETH into Aave V3 (Ethereum and Arbitrum), Compound V3, and Euler, borrowing over $236 million in real assets. Multiple reports estimate that Aave V3 alone faced bad debt of about $177 million. Aave’s security module, Umbrella, had about $50 million in WETH reserves to absorb bad debt, covering less than 30%, with the remaining risk borne by aWETH stakers.

In the end, this burden fell on those just trying to earn a little WETH interest.

LayerZero’s official statement, as of press time, is that they are working with the security emergency response organization SEAL Org to investigate, and will jointly release a post-incident report once all information is gathered. Kelp DAO said it is actively taking remedial measures.

The $293 million vulnerability was not in the code. The phrase “audit passed” does not cover the location of that parameter.