MetaMask Staking: 0.36 ETH Stolen, $1.4B of ETH Exited After a Fee Recipient Hijack

TL;DR

On September 30, 2026, MetaMask disclosed a security incident affecting part of its infrastructure and began exiting the affected validators in its non-custodial staking business, saying it had found no immediate threat to MetaMask wallets. Lido's node-operator forum carried the precautionary out-of-order exit disclosure the same day, identifying the operator as MetaMask Staking (formerly Consensys Staking). The theft itself was tiny: on-chain analyst Kaden found that 18 of 19 block rewards from suspected MetaMask validators went to a Tornado Cash funded address, about 0.36 ETH in total. The response was enormous: roughly 17,000 validators holding about 523,000 ETH, about $1.4 billion, are leaving the validator set. We pulled the relay data for all 18 blocks. Every one of them was delivered against a fee recipient that only that validator's own signing key could have authorized, and the operator's corrective re-registrations did not begin until four hours after the first diverted block. That is why 0.36 ETH justified a $1.4 billion exit: the stolen rewards prove that something got the signing keys to sign for the attacker. MetaMask has not published the attack vector.

What Happened to MetaMask Staking?

MetaMask Staking runs Ethereum validators for clients, Lido among them. On September 30 it told users it was "actively addressing and remediating the issue internally, in coordination with external partners and security advisors", and that as a precaution it was exiting affected validators. It stressed that the staking business is non-custodial and that it does not manage withdrawal keys for clients' stake.

Lido's disclosure gives the operational shape. The final MetaMask Staking validators were expected to be exited, though not fully withdrawn, by the end of October 7, 2026. The exits would likely incur foregone rewards and possible downtime penalties, and the exited ETH was expected to return to the protocol gradually over up to 45 days because of the long entry queue. Lido pointed to its diverse node-operator set and an ad hoc reserve fund of over 6,750 stETH as backstops.

The exit landed on the network's own queue. CryptoSlate reported 773,447 ETH waiting to exit, the largest backlog since December 2025, with a wait of 13 days and 10 hours before the withdrawal sweep.

What MetaMask has not said is just as important. There is no public statement on how the infrastructure was entered, whether validator signing keys were exposed, or exactly how many validators were affected. The 17,000 and 523,000 ETH figures are Kaden's on-chain estimates, as relayed by PANews and Protos, not MetaMask's.

What Is a Fee Recipient, and Why Does It Need a Signature?

A fee recipient is the execution-layer address that collects a validator's block rewards: priority fees, plus the payment a block builder makes for the right to fill the block. Most validators sell their block space through MEV-boost relays, and the relay has to know where to send that payment before the validator's slot comes up.

The validator tells it with a registration. Under the builder specification, the validator client assembles a ValidatorRegistrationV1 containing a fee_recipient, a gas limit, a timestamp and the validator's pubkey, signs it, and submits it to the builder network. The relay side then runs verify_registration_signature, a BLS check of that signature against the validator's own pubkey. A registration that the validator's key did not sign is rejected.

That key is the validator's signing key, the same key that signs blocks and attestations. It is the key whose misuse gets a validator slashed.

So a fee recipient is a signed statement. If a relay pays someone else's address, someone produced a valid signature from your validator key over their address.

How Did the Rewards End Up at a Tornado Cash Address?

The attacker's address is 0x98B9231de84334c1d48BA0b72CF13f92484924A3. Blockscout's internal-transaction record for the address shows its first activity: 0.0978 ETH out of a Tornado Cash 0.1 ETH pool at 10:27:23 UTC on September 30. Its next 18 inbound transfers are all builder payments.

The first arrived at 12:12:23 UTC in block 26090216, a Titan Builder block that paid 0.00817 ETH to the attacker's address. The relay's own record of that block shows the delivered payload with proposer_fee_recipient set to 0x98b9...24a3 for validator pubkey 0x84a7...cb32. The last diverted payment came at 16:46:11 UTC, a BuilderNet block that sent 0.0146 ETH to the same address.

We summed the 18 payments in that internal-transaction record: 0.3614 ETH, which matches Kaden's 0.36 ETH. None of it has moved. As of October 2 the address's counters show zero outgoing transactions, and its balance of about 0.459 ETH is the Tornado deposit plus every payment, untouched. We then looked up each of the 18 blocks in the relays' delivered-payload records. All 18 were MEV-boost deliveries, each from a different validator pubkey, and every bidtrace names the attacker's address as the fee recipient. Each of those deliveries required a registration that passed the relay's BLS check for that validator.

The repair is visible in the same data. A relay keeps only the newest registration per validator, and today the one for 0x84a7...cb32 points back at 0x388C...9297 with a timestamp of 16:10:11 UTC on September 30. Blockscout labels that address the LidoExecutionLayerRewardsVault. Across the 18 validators, the corrected registrations we pulled carry timestamps between 16:10:11 and 17:08:26 UTC. The latest of them, at 17:08:26, points at a different address, 0x2577...43B8. In our pull, eleven of the 18 point at the Lido vault and the other seven at five different addresses, which fits an operator running validators for more than one client.

The validator behind the 16:11:47 UTC diversion had its corrected registration timestamped 16:10:12, 95 seconds earlier, and still paid the attacker. A fix to a registration has to propagate through relays and builders. It does not land the moment you sign it.

The Attack, Step by Step

All times UTC, September 30, 2026. The registration timestamps are from relay data; the moment the attacker's registrations were signed is not public.

Two parties wrote to the same registration slot that afternoon, the attacker first and the operator four hours later:

Why Exit 523,000 ETH Over 0.36 ETH?

MetaMask's stated reason, through Lido's disclosure, is to reduce risks related to potential network penalties. Our reading of why that outweighs weeks of lost yield: the signing key is the asset at risk, and on Ethereum a signing key cannot be swapped out. A validator's pubkey lives in its registry record for life. The consensus specs define a validator as slashable from its activation epoch until its withdrawable_epoch, which is set to the exit epoch plus 256 epochs. Exiting is the only way to retire a key you no longer trust, and even an exited validator stays slashable for 256 epochs, about 27 hours, after its exit epoch.

There are two ways to get a validator key to sign a registration of your choosing. One is to hold the key. The other is to control the software that holds it. The standard Keymanager API that validator clients expose includes a setFeeRecipient call that "sets the validator client fee recipient mapping" per pubkey, guarded by a bearer token. The builder spec has validator clients re-submit signed registrations every epoch, so a changed mapping flows into the next registration the client signs.

The 18 payments are consistent with either path and rule out neither, and MetaMask has not said which it was. One detail is suggestive: the attacker used a single address for all 18 validators, which reads like one bulk change made from a central position rather than work done validator by validator (our inference). The two paths carry different risks. An attacker driving the validator client through its API still has to get past the client's slashing-protection database to make it double-sign. An attacker holding raw keys does not. The operator cannot rule out the second case from the outside, and with roughly 523,000 ETH behind those keys that is a bad bet to take on an incomplete investigation.

Our read of the attacker's choice, which no source has confirmed: a fee-recipient swap is about the only thing a validator key can sign that pays the signer's controller without slashing anyone, so 0.36 ETH bought a working test of access at almost no risk.

Kaden's analysis also leaves an open thread. PANews reports that three suspected affected validators had not exited and about 821 potentially affected validators remained active at the time of writing, and that it was unclear whether the attacker could change every fee recipient. Treat both as an analyst's estimate pending MetaMask's own count.

Have We Seen This Before?

Yes, and almost exactly a year ago. In September 2025, Kiln began an orderly exit of all its Ethereum validators after an exploit of its API hit SwissBorg for about 192,600 SOL. SwissBorg later relayed Kiln's finding that the entry point was the compromise of a GitHub access token belonging to a Kiln infrastructure engineer, which let the attacker inject a malicious payload into the Kiln Connect API.

The two incidents share a shape. In both, a staking operator's infrastructure was entered, the Ethereum validators themselves were not drained, and the operator still pulled every potentially exposed validator because it could not prove the signing path was clean. Kiln's breach came through a developer credential. MetaMask's vector is still unknown. Kiln's route went around the validator software entirely, and nothing MetaMask has published so far points at a client bug.

Audits do not cover this layer. An audit certifies the client code and the contracts you showed it. It says nothing about who holds the bearer token for your keymanager API, which engineer's GitHub token can ship to the signing service, or whether anyone is watching what your keys sign on an ordinary weekday afternoon.

Could This Have Been Caught Earlier?

Yes, by about four hours. Monitoring would not have prevented the intrusion or saved the first block's 0.00817 ETH. The gain here is time. The diversion ran from 12:12:23 to 16:46:11 UTC, and the first corrective registration is timestamped 16:10:11, which puts roughly four hours between the first observable signal and the first fix.

Three signals sat in that window, all public and all already cited above. The first two are on-chain.

1. A block your validator proposed paying a stranger. Block 26090216 carried a builder payment of 0.00817 ETH to 0x98b9...24a3 at 12:12:23. One mismatched payout is an incident. Eighteen of them is four and a half hours of keys signing for somebody else.
2. Who the stranger is. The recipient's only funding was 0.0978 ETH out of Tornado Cash less than two hours before the first payment. Once an unknown address shows up as a fee recipient, that funding history turns a config mismatch into a top-severity page.
3. A relay registration naming an address you do not own. This one lives off-chain: relays publish the newest registration for every pubkey, and an operator polling them sees the change before the first diverted block.

Alerting starts the clock rather than stopping the first payout. Signals one and two need only one plain sentence of rule: "page us when a block one of our validators proposed pays an address outside this list, and escalate if that address was funded from a mixer." Plain-English rules over on-chain activity, with alerts to the channels your team already watches, are what Tripwire runs. For an operator in MetaMask's position, that alert fires at 12:12 UTC on the first diverted block, hours before the corrective registrations began.

What Should Node Operators Do?

1. Allowlist your fee recipients and diff them continuously. Keep a per-pubkey map of the addresses each client expects, then poll relay registration data and your own beacon data against it. Any mismatch pages a human.
2. Treat the keymanager API as a signing interface. The fee-recipient endpoint can redirect every reward a validator earns. Keep it off any network the internet can reach, rotate its bearer token, and log every write to it.
3. Put a remote signer with slashing protection between keys and hosts. It narrows what an attacker who reaches a validator client can make the keys sign, and the remote signer is where you rotate or revoke access in one place.
4. Pre-sign and rehearse the exit. MetaMask and Kiln both reached the same answer: exit everything that might be exposed. Have the voluntary exits staged and the client communications drafted before you need them, because the exit queue does not care about your incident.
5. Watch what your keys sign as closely as the code that signs it. Developer credentials, CI tokens and API bearer tokens are the paths into the signing service. Inventory who can reach it and alert on access you did not schedule.

Frequently Asked Questions

Were MetaMask wallets affected?

No. MetaMask said it had identified no immediate threat to MetaMask wallets and no indication that wallets or customer funds were affected. The incident was confined to its non-custodial staking operations.

How much did the attacker steal?

About 0.36 ETH. We summed the 18 builder payments to the attacker's address at 0.3614 ETH, which matches Kaden's figure. The $1.4 billion figure is the value of the ETH being exited, not a loss.

Can the attacker withdraw the staked ETH?

No. Withdrawal credentials are a separate key from the signing key, and MetaMask says it does not manage withdrawal keys for clients. The open risk is slashing, which is why the validators are being exited.

Why do exits take so long?

The network rate-limits them. CryptoSlate measured an exit queue of 773,447 ETH with a 13-day, 10-hour wait, and Lido estimates the ETH could take up to 45 days to return to earning through the entry queue.

Has MetaMask published a postmortem?

Not yet. As of October 2, 2026, MetaMask has not disclosed the attack vector, whether signing keys were exposed, or a final count of affected validators.

The open question is the one MetaMask has not answered: whether the attacker held keys or only held the software that uses them. Until that is public, every operator running validators for clients should assume the second is enough to hurt them, and go check who can call their keymanager API.

Sources / References

• MetaMask, User update
• Lido Research Forum, [Security Disclosure] MetaMask Staking Precautionary Out of Order Exits
• The Hacker News, MetaMask Security Incident Prompts Exit of Affected Ethereum Validators
• Protos, MetaMask unstakes $1.4B of ETH after validator rewards stolen
• PANews, Analyst: Block rewards of 19 validators transferred in MetaMask security incident; about 523,000 ETH validators voluntarily exited
• CryptoSlate, MetaMask security scare pushes Ethereum validator exits to a nine-month high
• Blockscout, Attacker fee recipient address 0x98B9231de84334c1d48BA0b72CF13f92484924A3
• Blockscout API, Internal transactions for 0x98B9...24A3
• Blockscout API, First diverted builder payment, block 26090216
• Blockscout API, Last diverted builder payment, block 26091579
• Blockscout API, LidoExecutionLayerRewardsVault
• Ultra Sound Relay data API, Delivered payload for block 26090216
• Flashbots relay data API, Current validator registration for pubkey 0x84a7...cb32
• Flashbots relay data API, Current validator registration for pubkey 0xb484...6133
• Flashbots relay data API, Current validator registration for pubkey 0xae2c...3807
• Ethereum builder-specs, Bellatrix honest validator: validator registration
• Ethereum builder-specs, Bellatrix builder: verify_registration_signature
• Ethereum keymanager-APIs, Fee Recipient endpoints
• Ethereum consensus-specs, Phase 0 beacon chain: is_slashable_validator
• The Block, Kiln exits Ethereum validators in safety move after SwissBorg's $40 million hack
• SwissBorg, Kiln Breach (Sep 2025): Security Impact on SwissBorg