MetaMask has confirmed that an attacker briefly redirected the execution-layer rewards of certain Ethereum validators using its staking service, diverting roughly 0.385 ETH before the change was detected and reversed the same day. The details appeared in a November 5 incident update, the latest entry on a security incident the company first identified on September 28. Although the diverted amount was small, the episode highlights a frequently overlooked feature of Ethereum's design: the distinction between where a validator's staked ETH ultimately goes and where its ongoing reward income is sent.

What MetaMask Has Disclosed So Far

According to the update, the attacker gained unauthorized access to part of the infrastructure behind MetaMask Staking, where the addresses that collect validators' execution-layer rewards were stored centrally. The intruder changed those addresses for a number of validators. MetaMask says it found and fixed the modification the same day, after about 0.385 ETH in rewards had been diverted. The company has not disclosed how many validators were affected or how the attacker gained access.

The withdrawal side held. MetaMask Staking does not hold the withdrawal keys for customers' staked ETH, and the company says it found no evidence that staked principal, withdrawal keys or MetaMask wallets were compromised. Ordinary MetaMask wallet users do not need to take any action.

The 0.385 ETH does not represent the full cost of the incident. MetaMask exited every affected validator as a precaution, and all of those exits have now completed. Some customers experienced temporary withdrawal delays, and the company acknowledges that rewards may have been missed while validators were exiting or waiting to be staked again. MetaMask has not quantified those losses or said whether the diverted rewards will be reimbursed, stating only that it is working directly with affected customers and partners.

The reward diversion itself appears only in the November 5 entry. MetaMask's notices of September 30 and October 1 described the incident and the precautionary exits, and said at that stage there was no indication that wallets or customer funds had been affected. The number of validators involved, the attacker's point of entry and the question of reimbursement are the open items to watch in future updates from MetaMask.

Why the Stake Held but the Income Didn't

Every Ethereum validator answers to two addresses that are set in different places. Ethereum's withdrawal guidance treats withdrawal credentials and the fee recipient as distinct settings, even though both can point to the same wallet.

Withdrawal credentials are registered on the beacon chain. Once they point to an execution-layer address, that address cannot be changed, and it is where the validator's ETH goes when it exits. No operator server can redirect it.

The fee recipient works differently. It is a software setting supplied by whoever runs the validator. In a non-custodial service, that is the operator, which also holds the keys the validator signs with. The setting tells the network where to send execution-layer income each time the validator proposes a block: transaction priority fees and payments from block builders. The base fee, by contrast, is burned and never reaches the validator. The operator can update the fee recipient at any time without the staker's withdrawal key. This is the setting MetaMask says it stored centrally — and the one the attacker changed.

The same split explains why the loss stayed small. Consensus-layer rewards either remain in the validator's balance or are swept automatically to the withdrawal address, so the altered setting never touched them. Execution-layer income arrives only when a validator proposes a block, which any single validator does infrequently, and MetaMask fixed the change within a day. Only proposals made inside that window paid the wrong address.

The Same Exposure Runs Through Pooled Staking

Nothing about this exposure is unique to MetaMask. Wherever a third party runs the validator, the fee recipient sits in that third party's configuration, making the exposure a structural feature of third-party staking rather than a flaw confined to one provider. Lido, whose validators are operated by independent node operators, handles the risk by rule: its existing MEV policy requires every Lido validator to name the protocol's Execution Layer Rewards Vault as fee recipient, and violations already have their own handling process.

The vault is a contract. According to Lido's documentation, it collects execution-layer income, including MEV and priority fees, and only the main Lido contract can withdraw from it, moving the ETH into the protocol's accounting for stETH holders. A payment sent anywhere else never enters that accounting.

Holders of stETH stand one step further removed from these settings than MetaMask Staking customers. They own a transferable token rather than withdrawal credentials for any specific validator, so their protection rests entirely on Lido's contracts and operator rules.

ePBS Would Guarantee the Payment, Not the Address

On November 4, Lido published a proposal to update that MEV policy for enshrined proposer-builder separation, or ePBS, the design specified in EIP-7732. Validators that outsource block building today rely on relays, intermediaries trusted to ensure the winning builder actually pays. Lido describes ePBS as reducing the need for that trust by having the protocol itself guarantee builder payments.

The guarantee has limits. Under the design Lido describes, a single bid can combine a trustless value, owed as soon as the proposer includes the bid even if the builder never reveals its block, with an optional trusted payment settled outside the protocol, which carries the same counterparty risk as today's market. Lido would allow any registered builder to win its slots with fully trustless bids, but only builders on its vetted Allowed List could add trusted payments.

More consequential for stakers, the guarantee covers how much is paid, not where it lands. Under the design, validators broadcast signed preferences naming their fee recipient for upcoming slots, and the trustless value goes to the fee recipient named in the bid. That address still originates with the operator. A fee recipient altered in the way MetaMask described would receive guaranteed payments with the same certainty as the correct one.

Lido's draft keeps the fee-recipient rule at its core. Both payment types must reach the EL Rewards Vault, and the policy would bind every node able to propose for Lido, including backup and failover machines. Lido says the proposal goes to a vote in November and would take effect only after the Glamsterdam upgrade reaches Ethereum mainnet. Until that upgrade arrives, the existing MEV policy — with its vault rule — remains the standard Lido validators are held to.

What Lido's Checks Would Catch

Because ePBS opens additional routes for delivering a block, the proposal widens Lido's monitoring. A validator would be flagged for naming any address other than the vault, or for accepting a trusted payment from a builder outside the Allowed List. Flags would also cover trusted payments that fail to arrive in full within the settlement period, and locally built blocks proposed while eligible outside bids above the minimum threshold were available.

The bid-value check compares each selected bid with the highest eligible bid Lido's monitoring observed, flagging anything below an initial 90–95% of it. The threshold is a prompt for questions, not a promised share of income. The draft allows operators to pass over the top bid for legitimate operational and reliability reasons, and the comparison only covers bids Lido's own system observed.

A flag does not move money back. Fee-recipient violations remain under Lido's current process, while other flags would follow the outreach and escalation path in Section E of its Standard Node Operator Protocol. Lido also plans to update its public Fees Monitoring Dashboard to show which track each Lido block came through.

How to Check Your Own Staking Setup

Execution-layer payments are recorded on-chain, which is how the altered addresses at MetaMask became visible. A staker who knows their validator indices can open each block those validators proposed on a beacon chain explorer and check which address received the proposer's payment. For Lido, the fees dashboard is the public view of the pool's monitoring.

Exits deserve the same scrutiny. As MetaMask's update notes, exiting a validator and withdrawing its ETH are separate processes: an exited validator still has to clear Ethereum's withdrawal processing before the ETH is spendable, as described in Ethereum's staking documentation. Since the Pectra upgrade, EIP-7002 has allowed the holder of a validator's execution-layer withdrawal address to trigger its exit directly, without going through the operator.

Four questions to put to any staking provider cover the gaps this incident exposed:

Who can change my fee recipient? Look for named roles, sign-off before any change and a log of every edit, rather than one centrally stored setting.

How fast would you spot a wrong address? Look for automated checks on every proposed block, with alerts instead of periodic manual review.

Which builder payments are guaranteed? Under ePBS, expect a breakdown of protocol-enforced value versus trusted payments, and an explanation of how unpaid amounts are pursued.

Can I exit without you? Confirm your withdrawal credentials support self-triggered exits, and ask who covers rewards missed during a precautionary exit.