> 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/sep-30-incident-lido-steth-wsteth-validator-slashing-risk.md). # Sep 30: Incident - Lido (stETH/wstETH) validator slashing risk On September 30, 2026, MetaMask Staking (formerly Consensys Staking), one of the node operators in the Lido protocol, disclosed a compromise of its infrastructure and began exiting its Ethereum validators as a precaution. Because stETH can be deposited into ether.fi to mint weETH, and Lido has had validators slashed before, we paused stETH deposits while we assessed whether the incident could lead to slashing losses in stETH. After the assessment, we unpaused deposits the next day. **No ether.fi user funds were affected, and no ether.fi validator was involved.** ### What Ethereum validator slashing is Slashing is a penalty Ethereum takes out of a validator's staked ETH when the validator provably breaks the rules, for example by signing two conflicting blocks or votes. The usual cause is an operator's signing keys running in two places at once, which can happen through misconfiguration or when an attacker gains access to the operator's infrastructure. A slashed validator loses part of its stake and is removed from staking. For how slashing applies to ether.fi, see [Slashing Risk](/etherfi/security/security-and-risks/slashing-risk.md). For the full protocol rules, see the [Ethereum proof-of-stake rewards and penalties documentation](https://ethereum.org/en/developers/docs/consensus-mechanisms/pos/rewards-and-penalties/). ### What happened at MetaMask Staking On September 30, MetaMask [reported](https://metamask.io/news/user-update) "an ongoing security incident affecting part of our infrastructure" and said it was exiting affected validators in its staking business as a precaution. It said it had found no threat to MetaMask wallets and that it does not hold the withdrawal keys for staked ETH, so an attacker with access to its infrastructure could not withdraw client stake. A day later it said there was no indication that wallets or customer funds had been affected. MetaMask has not said which systems were compromised, how, or how many validators were involved. On-chain data shows what the attacker did with that access. Every validator signs a message naming the address that should receive its block rewards. On September 30, 18 blocks from validators attributed to MetaMask Staking paid their rewards to an attacker address instead, which means the attacker could get valid signatures from those validators, either through their signing keys or through the software that manages them: * **10:27 UTC:** The attacker address [`0x98B9231de84334c1d48BA0b72CF13f92484924A3`](https://etherscan.io/address/0x98B9231de84334c1d48BA0b72CF13f92484924A3) received 0.0978 ETH from a Tornado Cash pool. * **12:12 to 16:46 UTC:** 18 block rewards totaling about 0.36 ETH were paid to that address. * **October 7:** The address sent 0.4 ETH back into Tornado Cash. The stolen rewards were small. The larger risk was what else the attacker could sign. With the same access, an attacker could in principle make validators sign conflicting messages, which is exactly what gets validators slashed. No slashing has been reported from this incident. An independent analyst [estimated](https://decrypt.co/379800/metamask-exits-lido-validators-amid-infrastructure-security-incident) that about 17,000 validators holding roughly 523,000 ETH are being exited as a precaution; MetaMask has not confirmed that figure. ### What happened at Lido Lido [disclosed the incident on its governance forum](https://research.lido.fi/t/security-disclosure-metamask-staking-precautionary-out-of-order-exits/11961) and [on X](https://x.com/LidoFinance/status/2105443679905235344) late on September 30. It said MetaMask Staking was exiting all of its validators in the Lido protocol, that the exits could cost staking rewards and incur downtime penalties, and that stETH holders did not need to take any action. Lido pointed to its spread of node operators and a reserve fund of more than 6,750 stETH as buffers. The exits were expected to finish by October 7, and on that date Lido [reported](https://panews.io/articles/01a1110c-7554-7069-961b-27cb93314a8e) them nearly complete with no new anomalies. On October 5, Lido contributors [proposed](https://research.lido.fi/t/security-disclosure-metamask-staking-precautionary-out-of-order-exits/11961) stopping new stake allocations to MetaMask Staking through the next on-chain vote. ### Lido's previous slashing incidents Lido has had validators slashed before. Both past incidents were covered by the operator, and stETH holders did not lose rewards: | Date | Operator | Validators slashed | Cause | Covered by | Source | | ------------ | ------------------------------------- | ------------------ | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------- | | Oct 11, 2023 | Launchnodes | 20 | During a data center failover, two validator clients signed through the same signer, which had no slashing protection, producing duplicate attestations. Projected penalties and missed rewards were about 28.7 ETH. | Launchnodes paid 25.663 ETH into Lido's rewards vault and pledged to cover further penalties | [Lido post-mortem](https://blog.lido.fi/post-mortem-launchnodes-slashing-incident/) | | Mar 2026 | One Community Staking Module operator | 6 | Not disclosed. Penalties expected under 1 ETH. | The operator's stETH bond | [Lido forum](https://research.lido.fi/t/incident-minor-csm-operator-slashing/11281) | These incidents show that slashing at a large operator set is a real, recurring event, not a theoretical one. The September 30 incident was more serious in kind: it involved an attacker, not a configuration mistake, and it touched a much larger share of Lido's validators. ### Why it mattered to ether.fi ether.fi's validators are run by ether.fi's own operator set, so the compromised infrastructure did not touch ether.fi's stake. The exposure was indirect: users can deposit stETH into ether.fi to mint weETH, and stETH accepted this way is held by the protocol. If the compromised operator's validators had been slashed at scale, stETH's value could have dropped, and stETH accepted at full value during that window would have passed the loss to eETH and weETH holders. ### What we did 1. **Paused stETH deposits.** Given the attacker's demonstrated signing access and Lido's history of slashing events, we paused the stETH deposit rather than wait to see whether slashing followed. This stopped new stETH from being deposited to mint weETH. The pause did not affect existing weETH or eETH balances, and transfers or withdrawals. 2. **Assessed the risk.** We reviewed Lido's disclosure, the scope of the affected operator's validators, and Lido's protections, including its spread of node operators and its reserve fund of more than 6,750 stETH. 3. **Unpaused stETH deposits.** Once the assessment concluded that the remaining risk to stETH was limited, the Operating Multisig lifted the pause early, about 15.5 hours after it started. ### Timeline (UTC) * **Sep 30, 10:27:23**: Attacker address funded from Tornado Cash. * **Sep 30, 12:12:23**: First block reward diverted to the attacker address, block 26,090,216. * **Sep 30, 16:46:11**: Last diverted block reward, block 26,091,579. * **Sep 30, 22:48:11**: stETH deposit paused, block 26,093,379. * **Sep 30, 23:44**: Lido's public announcement on X. * **Oct 1, 14:26:47**: stETH deposit unpaused by the Operating Multisig, block 26,098,057. ### Outcome The pause closed the only path through which the incident could have reached ether.fi, and it was lifted within a day once the risk was understood. This is how our pause controls are designed to work: act first on a credible risk, then restore normal service quickly. ether.fi's own record is unchanged. **No ether.fi validator has been slashed since the protocol launched.** ether.fi also holds [up to 15,000 ETH of slashing cover with Nexus Mutual](https://nexusmutual.io/blog/a-new-layer-of-protection-for-ether.fi) for its own validators. --- # 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 by asking a question. Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters: ``` GET https://etherfi.gitbook.io/etherfi/security/security-and-risks/incident-management/sep-30-incident-lido-steth-wsteth-validator-slashing-risk.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case. 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.