> For the complete documentation index, see [llms.txt](https://etherfi.gitbook.io/etherfi/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://etherfi.gitbook.io/etherfi/security/security-and-risks/incident-management/apr-18-incident-kelp-rseth-bridge-exploit.md).

# Apr 18: Incident - Kelp rsETH bridge exploit (third-party)

On April 18, 2026, KelpDAO's rsETH bridge was exploited for approximately $292M in unbacked rsETH. Attackers forged a LayerZero cross-chain message that Kelp's bridge accepted because its configuration relied on a single verifier (a 1-of-1 DVN setup). **No ether.fi systems were compromised, weETH was unaffected and fully backed throughout, and Liquid vaults held no rsETH** — it had failed the pre-deposit risk checklist. This page documents how ether.fi responded to the ecosystem-wide fallout, and links the permanent hardening that followed.

**Why ether.fi was not exposed:**

* Kelp's fatal configuration was a bridge route where compromising one verifier was enough to mint unbacked tokens. The same evening, ether.fi ran an exposure sweep of every weETH bridge route across all 20 chains: **zero routes matched that configuration**. Every weETH route required at least 2 independent verifiers (3 on the highest-traffic routes), so the attack pattern had no direct analogue against weETH.
* The remaining risk was second-order: market-wide stress in borrow markets and any shared bridge infrastructure. That is what the response below contained.

**Timeline of the response:**

* **Apr 18, 2:03 PM ET** — Team flagged the Kelp exploit and assembled a war room to assess second-order effects: exposure to lending markets, the shared LayerZero messaging layer, and leveraged positions reacting to the news.
* **Afternoon** — Two parallel workstreams: deleveraging the highest-risk positions (withdrawal requests placed to repay borrow-market debt), and a full audit of vault state across all products and chains.
* **5:02 PM ET** — All Liquid vaults paused across every chain as a precaution (liquidETH, liquidUSD, liquidBTC, eBTC, sETHFI, eUSD). The paused contract also carries bridge operations, so deposits, withdrawals, and bridging halted together. This was precautionary — not a loss of funds.
* **Evening** — Root cause isolated to Kelp's LayerZero verifier configuration; the weETH exposure sweep across all 20 chains confirmed no equivalent weakness.
* **10:11 PM ET** — LayerZero messaging disabled across vaults, so that when vaults reopened, bridging would stay off until hardening was in place.
* **Apr 19 (morning)** — Deposits and withdrawals reopened: a **\~1 day pause**. Bridging remained off. A temporary extended withdrawal window was added while deleveraging worked through stressed market conditions; fewer than 8 withdrawals failed during this period, and all were expedited.
* **Apr 19–23** — Cleanup under elevated borrow rates: debt in lending markets repaid, validators proactively exited to bring rates down, additional DEX liquidity deployed to help levered users exit, and the elevated borrow costs absorbed by ether.fi to sustain user yields.
* **Apr 23** — Bridging restored behind hardened settings: unanimous 4-of-4 verifier requirement, message libraries pinned, and source-chain confirmation requirements raised.

**Permanent hardening:**

The incident revealed a latent ecosystem-wide risk: a bridge provider's own multisig could modify protocol-wide defaults that applications relied on. ether.fi closed this permanently across all 20 weETH chains — message libraries pinned into weETH's own configuration, the 4-DVN verifier set pinned with a unanimous 4-of-4 threshold, and pair-wise rate limits tightened on ether.fi-owned contracts. Every security-relevant bridge parameter is now controlled exclusively by ether.fi multisigs. The full technical write-up is in the [weETH bridge security hardening blog post](https://www.ether.fi/blog/weeth-bridge-security-hardening), and the resulting controls are documented in [MultiSigs & Controls](/etherfi/security/security-and-risks/multisigs-and-controls.md).

As part of the follow-up L2 risk assessment, weETH bridging was deprecated on Scroll, Swell, Bera, zkSync, Mode, Blast, Morph, and Sonic, effective end of June 2026.

ether.fi also joined [DeFi United](https://x.com/aave/status/2048189931856535887), an ecosystem coalition formed after the incident to standardize bridge security and coordinate incident response, and [contributed to its dedicated relief vehicle](https://x.com/ether_fi/status/2047393577920299364).

We're glad to report that no ether.fi user funds were lost, weETH remained fully backed on every chain throughout, and the precautionary vault pause was lifted within a day.


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://etherfi.gitbook.io/etherfi/security/security-and-risks/incident-management/apr-18-incident-kelp-rseth-bridge-exploit.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.
