Skip to content
#06 largest Access control 2026

The KelpDAO rsETH hack — $291M lost

Loss$291M
Date18 Apr 2026
ChainEthereum ↔ Unichain
Failure classAccess control
In assets116,500 rsETH
TargetLayerZero OFT adapter
1

What happened

The most recent entry on this list, and the one that should worry builders most: the contracts had no bug at all. Kelp's rsETH adapter on the Unichain→Ethereum path was configured to require exactly one verifier (DVN) — LayerZero Labs — despite LayerZero's own integration checklist recommending a redundant multi-verifier setup. Six weeks earlier, attackers had socially engineered a LayerZero developer, pivoted into the RPC cloud environment, and poisoned the nodes that verifier reads from. The adapter then released 116,500 rsETH in response to a message that no Unichain transaction ever emitted.

2

How the attack ran

  1. Social-engineer a developerLayerZero Labs, six weeks before the theft
  2. Poison the verifier’s RPC nodesThe DVN now reports attacker-supplied chain state
  3. requiredDVNs.length == 1One verifier means compromising it IS compromising the bridge
  4. Released on a ghost message116,500 rsETH for a Unichain tx that never existed
3

The code

the vulnerability was a config value, not a line of Solidity
// LayerZero endpoint config for the Unichain → Ethereum pathway
UlnConfig {
  requiredDVNs:          [ LayerZeroLabsDVN ],   // ❌ length = 1
  optionalDVNs:          [ ],
  optionalDVNThreshold:  0
}

// ✅ what the integration checklist recommends
UlnConfig {
  requiredDVNs:          [ LayerZeroLabsDVN, PartnerDVN ],
  optionalDVNs:          [ DVN_A, DVN_B, DVN_C ],
  optionalDVNThreshold:  2
}

// With one verifier, compromising one verifier's data feed
// IS compromising the bridge. Poison its RPC → forge any message.
→ result: $291M released for a message that never existed
4

What would have caught it

◆
What an audit looks for: deployed configuration, not just source code. Trust thresholds, oracle sets, verifier counts, timelock delays and admin keys are all part of the attack surface — and unlike code, they can be silently changed after the audit. A review that stops at the .sol file would have signed off on this one.
5

The vulnerability classes behind it

Entries in the SAFE database that describe this failure. These share its failure class.

SAFE-0006Missing Access Control on Privileged Function critical · Access Control SAFE-0008Unprotected Initializer / Initialization critical · Access Control SAFE-0010Privilege Escalation via Role Misconfiguration critical · Access Control SAFE-0015Backdoor / Hidden Privileged Function critical · Access Control SAFE-0033Storage Collision in Proxy / Delegatecall critical · Upgradeability SAFE-0034Upgradeable Storage Layout Corruption critical · Upgradeability SAFE-0035UUPS Upgrade Authorization Bug critical · Upgradeability SAFE-0036Proxy Admin Takeover critical · Upgradeability SAFE-0116Unprotected selfdestruct critical · Access Control
6

Sources

LayerZero — incident reportOpenZeppelin — lessonsChainalysis

Every figure on this page comes from the post-mortems above, not from us. Losses are US dollars at the time of the incident.

← #05 — largerWormhole · $326M
Check your own contract for this

Access control is one of the 203 classes the SaferICO scanner checks for. It will not review your signing process — but it will read your Solidity.

Run the scanner See how it is attacked Read the docs