Image Generated by Gemini AI. Compromised nodes providing wrong Source Blockchain State data to LayerZero DVN
Evolution of Web3 Bridge Exploits: From Code Vulnerabilities to Data Manipulation
Web3 attackers are increasingly conducting sophisticated attacks on bridge protocols — targeting weaknesses in security configurations and verification processes, rather than just smart contract bugs.
Traditionally, exploits focused on:
• vulnerabilities in token-holding smart contracts
• or compromising validator keys in more centralized bridge architectures
However, attackers have now expanded their approach — manipulating how systems verify cross-chain state.
Hyperbridge Exploit: A Critical Gap in Proof Verification Logic
Consider the Hyperbridge exploit I discussed earlier.
The attacker tricked the TokenGateway smart contract into approving a malicious message by submitting a valid proof copied from previous transaction state commitments.
This was possible because Hyperbridge’s Merkle Mountain Range verification process did not ensure that the submitted proof corresponded to the specific transaction being validated.
Hyperbridge Exploit Explained: How a Valid Proof Was Used to Mint $1B Fake DOT
LayerZero Exploit: When Verifiers Are Misled by a Fabricated View of the Blockchain
A more recent case involved Kelp DAO, where an attacker moved 116,500 rsETH from its LayerZero bridge adapter.
The exploit worked by fooling the Decentralized Versifier Network (DVN) operated by LayerZero Labs into believing that an ETH burn event had occurred on the source chain — when no such event actually took place.
🧠 Key difference from earlier exploits
• Hyperbridge relied on cryptographic verification (Merkle proofs)
• LayerZero DVN relied on RPC-based state queries
In this case, the attack did not break cryptography — it corrupted the data source used for verification.
👉 Dissecting the Attack: Weaknesses in Verification Design and RPC Infrastructure
KelpDAO had configured its bridge to use the default LayerZero setup, where:
• A single DVN verifies cross-chain transactions
• The DVN queries blockchain state using three RPC endpoints:
o Two internal RPC nodes operated by LayerZero
o One external third-party RPC
LayerZero stated that its internal RPC nodes were:
• deployed in separate clusters
• not directly connected
However, both nodes ran similar client software (op-geth) and served the same role.
Compromising the Data Layer: How LayerZero’s RPC Nodes Were Manipulated
LayerZero DVN mislead to believe that ETH Burn event happened in Source chain
The attacker:
• Gained access to the RPC infrastructure used by the DVN
• Replaced binaries on the internal RPC nodes (running op-geth)
• Launched a DDOS attack on the external RPC
The compromised RPC nodes then performed a selective spoofing attack:
• Returned false data (phantom ETH burn event) only when queried by the DVN
• Returned correct data to all other observers, including monitoring systems
This ensured:
• No alerts were triggered
• External checks appeared normal
Phantom Events, Real Consequences: Approving Transactions Without On-Chain Reality
The DVN:
• Queried compromised RPC nodes
• Received a fabricated view of the blockchain
• Verified a non-existent burn event
• Approved the transaction
As a result, 116,500 rsETH was released to the attacker.
⚠️ Core weaknesses exposed
• Reliance on a single DVN
• Limited and correlated RPC data sources
• Absence of independent verification paths
Simply increasing the number of verifiers is not sufficient.
True security requires both:
• multiple DVNs
• and independent data sources across those DVNs
Key lessons
• RPC infrastructure is not inherently trustworthy
• Even “independent nodes” can be independently compromised
• Verification systems must assume Byzantine behavior, not just failure
Stronger setups would involve:
• Multiple DVNs
• Diverse RPC providers (different clients, regions, infrastructure)
• Preferably proof-based verification mechanisms
KelpDAO’s Response: Containment, Blacklisting, and Preventing Further Loss
After detecting the exploit, KelpDAO:
• Blacklisted attacker addresses
• Paused contract interactions across chains
• Prevented an additional attempt to drain ~49,000 rsETH
Additionally, 30,766 ETH bridged to Arbitrum was recovered.
The Arbitrum DAO Security Council intervened and moved the funds to a secure recovery address, as they were still within protocol-controlled infrastructure.
Image and Content Credits -:
Banner and Graphic Explainer Generated by Gemini
Incident Details understood from these Sources –
Inside the KelpDAO Bridge Exploit: How ~$292 Million in rsETH Was Released Against a Non-Existent Burn
LayerZero explanation post on X - https://x.com/LayerZero_Core/status/2046081551574983137
KelpDAO explanation post on X - https://x.com/KelpDAO/status/2046332070277091807