MetaMask hat bestätigt, dass ein Angreifer vorübergehend die Execution-Layer-Belohnungen bestimmter Ethereum-Validatoren über seinen Staking-Dienst umgeleitet hat; dabei wurden rund 0,385 ETH abgezweigt, bevor die Änderung noch am selben Tag erkannt und zurückgenommen wurde. Die Details erschienen in einem Incident-Update vom 5. November, dem neuesten Eintrag zu einem Sicherheitsvorfall, den das Unternehmen erstmals am 28. September festgestellt hatte. Obwohl der umgeleitete Betrag gering war, macht der Vorfall ein häufig übersehenes Merkmal des Ethereum-Designs deutlich: den Unterschied zwischen dem Ziel des gestakten ETH eines Validators und dem Ort, an den seine laufenden Belohnungen gesendet werden.

Was MetaMask bisher offengelegt hat

Laut dem Update erlangte der Angreifer unbefugten Zugriff auf einen Teil der Infrastruktur hinter MetaMask Staking, in dem die Adressen zentral gespeichert waren, die die Execution-Layer-Belohnungen der Validatoren einziehen. Der Eindringling änderte diese Adressen für eine Reihe von Validatoren. MetaMask sagt, es habe die Änderung noch am selben Tag entdeckt und behoben, nachdem etwa 0,385 ETH an Belohnungen umgeleitet worden waren. Das Unternehmen hat nicht offengelegt, wie viele Validatoren betroffen waren oder wie der Angreifer Zugriff erlangte.

Die Auszahlungsseite blieb unberührt. MetaMask Staking verwahrt keine Withdrawal Keys für das gestakte ETH der Kunden, und das Unternehmen sagt, es habe keine Hinweise darauf gefunden, dass gestaktes Kapital, Withdrawal Keys oder MetaMask-Wallets kompromittiert wurden. Gewöhnliche MetaMask-Wallet-Nutzer müssen keine Maßnahmen ergreifen.

Die 0,385 ETH stellen nicht die Gesamtkosten des Vorfalls dar. MetaMask hat alle betroffenen Validatoren vorsorglich exited, und alle diese Exits sind inzwischen abgeschlossen. Einige Kunden hatten vorübergehende Auszahlungsverzögerungen, und das Unternehmen räumt ein, dass Belohnungen entgangen sein können, während Validatoren ausstiegen oder darauf warteten, erneut gestakt zu werden. MetaMask hat diese Verluste nicht beziffert und nicht gesagt, ob die umgeleiteten Belohnungen erstattet werden, sondern nur erklärt, dass es direkt mit betroffenen Kunden und Partnern arbeitet.

Die Belohnungsumleitung selbst taucht erst im Eintrag vom 5. November auf. MetaMasks Mitteilungen vom 30. September und 1. Oktober beschrieben den Vorfall und die vorsorglichen Exits und erklärten, es gebe zu diesem Zeitpunkt keine Hinweise darauf, dass Wallets oder Kundengelder betroffen waren. Die Zahl der beteiligten Validatoren, der Einstiegspunkt des Angreifers und die Frage der Erstattung sind die offenen Punkte, die man in künftigen Updates von MetaMask beobachten sollte.

Warum das Staking hielt, die Einnahmen aber nicht

Jeder Ethereum-Validator hat zwei Adressen, die an unterschiedlichen Stellen festgelegt werden. Ethereums Auszahlungsrichtlinie behandelt Withdrawal Credentials und den Fee Recipient als getrennte Einstellungen, obwohl beide auf dieselbe Wallet verweisen können.

Withdrawal Credentials werden auf der Beacon Chain registriert. Sobald sie auf eine Execution-Layer-Adresse verweisen, kann diese Adresse nicht mehr geändert werden, und sie ist das Ziel des ETH des Validators beim Exit. Kein Operator-Server kann sie umleiten.

Der Fee Recipient funktioniert anders. Es ist eine Software-Einstellung, die von demjenigen bereitgestellt wird, der den Validator betreibt. Bei einem Non-Custodial-Dienst ist das der Operator, der auch die Schlüssel verwahrt, mit denen der Validator signiert. Die Einstellung legt fest, wohin das Netzwerk die Execution-Layer-Einnahmen jedes Mal sendet, wenn der Validator einen Block vorschlägt: Transaktions-Priority-Fees und Zahlungen von Block Buildern. Die Base Fee dagegen wird verbrannt und erreicht den Validator nie. Der Operator kann den Fee Recipient jederzeit ohne den Withdrawal Key des Stakers aktualisieren. Genau diese Einstellung habe MetaMask zentral gespeichert — und genau sie hat der Angreifer geändert.

Dasselbe Aufteilungsprinzip erklärt, warum der Verlust gering blieb. Konsens-Layer-Belohnungen verbleiben entweder im Guthaben des Validators oder werden automatisch zur Auszahlungsadresse übertragen, sodass die geänderte Einstellung sie nie berührte. Execution-Layer-Einnahmen fließen nur, wenn ein Validator einen Block vorschlägt, was ein einzelner Validator selten tut, und MetaMask behob die Änderung innerhalb eines Tages. Nur Vorschläge in diesem Zeitfenster zahlten an die falsche Adresse.

Dieselbe Anfälligkeit betrifft das Pool-Staking

Diese Anfälligkeit ist nichts, was es nur bei MetaMask gibt. Wo immer ein Dritter den Validator betreibt, liegt der Fee Recipient in dessen Konfiguration, wodurch die Anfälligkeit ein strukturelles Merkmal des Stakings durch Dritte ist und kein Fehler eines einzelnen Anbieters. Lido, dessen Validatoren von unabhängigen Node-Operatoren betrieben werden, regelt das per Vorschrift: Seine bestehende MEV-Richtlinie verlangt von jedem Lido-Validator, den Execution Layer Rewards Vault des Protokolls als Fee Recipient anzugeben, und Verstöße haben bereits einen eigenen Handlungsprozess.

Der Vault ist ein Smart Contract. Laut Lidos Dokumentation sammelt er Execution-Layer-Einnahmen einschließlich MEV und Priority Fees, und nur der zentrale Lido-Contract kann daraus abheben, wodurch das ETH in die Protokoll-Verrechnung für stETH-Halter fließt. Eine an eine andere Stelle gesendete Zahlung gelangt nie in diese Verrechnung.

stETH-Halter sind noch eine Stufe weiter von diesen Einstellungen entfernt als MetaMask-Staking-Kunden. Sie besitzen ein übertragbares Token statt Withdrawal Credentials für einen bestimmten Validator, ihr Schutz beruht also vollständig auf Lidos Contracts und Operator-Regeln.

ePBS garantiert die Zahlung, nicht die Adresse

Am 4. November veröffentlichte Lido einen Vorschlag zur Aktualisierung dieser MEV-Richtlinie für die enshrined proposer-builder separation, kurz ePBS, das in EIP-7732 spezifizierte Design. Validatoren, die den Blockbau heute auslagern, verlassen sich auf Relays — Vermittler, denen man vertraut, dass der gewinnende Builder tatsächlich zahlt. Lido beschreibt ePBS als Reduzierung dieses Vertrauensbedürfnisses, indem das Protokoll selbst Builder-Zahlungen garantiert.

Die Garantie hat Grenzen. Nach dem von Lido beschriebenen Design kann ein einzelnes Gebot einen trustless Wert, der sofort fällig wird, sobald der Proposer das Gebot einbezieht, selbst wenn der Builder seinen Block nie offenlegt, mit einer optionalen Trusted Payment kombinieren, die außerhalb des Protokolls abgewickelt wird und dasselbe Kontrahentenrisiko birgt wie der heutige Markt. Lido würde jedem registrierten Builder erlauben, seine Slots mit vollkommen trustless Geboten zu gewinnen, doch nur Builder auf seiner geprüften Allowed List könnten Trusted Payments hinzufügen.

Für Staker wichtiger ist: Die Garantie betrifft, wie viel gezahlt wird, nicht wohin es fließt. Nach dem Design übertragen Validatoren signierte Präferenzen, die ihren Fee Recipient für kommende Slots benennen, und der trustless Wert geht an den im Gebot genannten Fee Recipient. Diese Adresse stammt weiterhin vom Operator. Ein in der von MetaMask beschriebenen Weise veränderter Fee Recipient erhielte garantierte Zahlungen mit derselben Sicherheit wie die korrekte Adresse.

Lidos Entwurf behält die Fee-Recipient-Regel im Kern bei. Beide Zahlungsarten müssen den EL Rewards Vault erreichen, und die Richtlinie würde jeden Node binden, der für Lido vorschlagen kann, einschließlich Backup- und Failover-Maschinen. Lido sagt, der Vorschlag gehe im November zur Abstimmung und werde erst wirksam, nachdem das Glamsterdam-Upgrade das Ethereum-Mainnet erreicht habe. Bis dahin bleibt die bestehende MEV-Richtlinie mit ihrer Vault-Regel der Maßstab, an dem Lido-Validatoren gemessen werden.

Was Lidos Kontrollen erfassen würden

Da ePBS zusätzliche Wege zur Blockzustellung eröffnet, weitet der Vorschlag Lidos Überwachung aus. Ein Validator würde markiert werden, wenn er eine andere Adresse als den Vault angibt, oder wenn er eine Trusted Payment von einem Builder außerhalb der Allowed List akzeptiert. Markierungen würden auch Trusted Payments erfassen, die nicht vollständig innerhalb des Abwicklungszeitraums eintreffen, sowie lokal gebaute Blöcke, die vorgeschlagen wurden, während qualifizierte externe Gebote oberhalb der Mindestschwelle verfügbar waren.

Die Gebotswert-Prüfung vergleicht jedes ausgewählte Gebot mit dem höchsten beobachteten qualifizierten Gebot in Lidos Überwachung und markiert alles unterhalb einer anfänglichen Schwelle von 90–95 % davon. Die Schwelle ist ein Anlass für Nachfragen, kein zugesagter Anteil der Einnahmen. Der Entwurf erlaubt Operatoren, das Top-Gebot aus legitimen operativen und Zuverlässigkeitsgründen zu überspringen, und der Vergleich erfasst nur Gebote, die Lidos eigenes System beobachtet hat.

Eine Markierung bringt kein Geld zurück. Fee-Recipient-Verstöße bleiben im bestehenden Prozess von Lido, während andere Markierungen dem Outreach- und Eskalationspfad in Abschnitt E seines Standard Node Operator Protocol folgen würden. Lido plant außerdem, sein öffentliches Fees Monitoring Dashboard zu aktualisieren, um anzuzeigen, über welchen Weg jeder Lido-Block zustande kam.

So prüfen Sie Ihr eigenes Staking-Setup

Execution-Layer-Zahlungen werden on-chain aufgezeichnet, weshalb die veränderten Adressen bei MetaMask sichtbar wurden. Ein Staker, der seine Validator-Indizes kennt, kann jeden von diesen Validatoren vorgeschlagenen Block in einem Beacon-Chain-Explorer öffnen und prüfen, welche Adresse die Proposer-Zahlung erhalten hat. Bei Lido ist das Fees Dashboard die öffentliche Sicht auf die Überwachung des Pools.

Exits verdienen dieselbe Prüfung. Wie MetaMask in seinem Update anmerkt, sind der Exit eines Validators und das Abheben seines ETH getrennte Prozesse: Ein exited Validator muss noch Ethereums Auszahlungsverarbeitung durchlaufen, bevor das ETH verfügbar ist, wie in Ethereums Staking-Dokumentation beschrieben. Seit dem Pectra-Upgrade ermöglicht EIP-7002 dem Inhaber der Execution-Layer-Auszahlungsadresse eines Validators, dessen Exit direkt auszulösen, ohne den Operator einzubeziehen.

Vier Fragen an jeden Staking-Anbieter decken die Lücken ab, die dieser Vorfall offengelegt hat:

Wer kann meinen Fee Recipient ändern? Achten Sie auf benannte Rollen, eine Freigabe vor jeder Änderung und ein Protokoll jeder Bearbeitung, statt einer zentral gespeicherten Einstellung.

Wie schnell würden Sie eine falsche Adresse bemerken? Achten Sie auf automatisierte Prüfungen jedes vorgeschlagenen Blocks mit Warnungen statt periodischer manueller Überprüfung.

Welche Builder-Zahlungen sind garantiert? Bei ePBS erwarten Sie eine Aufschlüsselung von protokollerzwungenem Wert gegenüber Trusted Payments und eine Erklärung, wie unbezahlte Beträge verfolgt werden.

Kann ich ohne Sie exiten? Bestätigen Sie, dass Ihre Withdrawal Credentials selbst ausgelöste Exits unterstützen, und fragen Sie, wer entgangene Belohnungen während eines vorsorglichen Exits abdeckt.