Ledger behebt Sicherheitslücke in Ethereum-App: Signaturen konnten von angezeigten Transaktionsdaten abweichen

Wer einen Ledger nutzt und damit Ether oder ERC20-Token verwaltet, sollte in Ledger Live prüfen, welche Version der Ethereum-App auf dem Gerät installiert ist. Alles unter 1.22.2 enthält keinen wichtigen Sicherheitsfix. Die Korrektur schließt eine Schwachstelle, die ausgerechnet das zentrale Sicherheitsversprechen von Hardware-Wallets angreift: dass das Display verlässlich zeigt, was das Gerät gleich signiert. Öffentlich wurde der Fall am 24. August 2026, als die Sicherheitsfirma TestMachine ihre Analyse veröffentlichte. Der Fix existierte zu diesem Zeitpunkt bereits; zwischen Veröffentlichung und Auslieferung gibt es Streit darüber, wer die Lücke zuerst gefunden hat und wann Ledger sie ausgeliefert hat. Für Nutzer ist entscheidend: Version 1.22.2 oder höher installieren und anschließend prüfen, welche Freigaben (Approvals) in der Vergangenheit erteilt wurden. Was genau betroffen war Betroffen war weder die Firmware des Geräts noch die Verwahrung des Private Keys. Die Schwachstelle steckte in der Ethereum-App auf dem Gerät, also der Zusatzsoftware für Ether und ERC20-Token. Diese App bereitet Transaktionen auf, zeigt sie zur Prüfung an und holt die Bestätigung ein. In fehlerhaften Versionen ließ sich diese Abfolge durcheinanderbringen. Eine bösartige Web-Anwendung mit Zugriff auf das angeschlossene Gerät konnte einen zweiten Signierbefehl senden, während die erste Transaktion noch auf dem Display zur Prüfung stand. Dabei wurden die Daten im Speicher ausgetauscht, ohne dass eine neue Prüfansicht eingeblendet wurde. Auf dem Bildschirm blieb die zuvor geprüfte, harmlose Transaktion sichtbar, die Bestätigung galt aber den ausgetauschten Daten. Laut den Forschern wurde das Muster auf einem Ledger Flex reproduzierbar nachgestellt. Da die Geräte weitgehend denselben Code der Ethereum-App nutzen, gelten auch Nano X, Nano S Plus, Stax und Apex als potenziell betroffen. Ledger hat nicht offengelegt, ab welcher App-Version der Fehler erstmals enthalten war; die Gegenüberstellung der Forscher beginnt bei 1.22.1 (zuvor getaggte Version vom 27. Mai 2026). "Clear Signing": warum das Display das eigentliche Sicherheitsversprechen ist Unter "Clear Signing" versteht man, dass eine Hardware-Wallet vor der Bestätigung die vollständigen Transaktionsdaten im Klartext auf dem eigenen Display anzeigt: Empfängeradresse, Betrag und bei Contract-Calls die beabsichtigte Aktion. Genau dafür existieren Hardware-Wallets: Computer und Browser können kompromittiert sein, Oberflächen manipuliert oder Websites gefälscht. Solange das Gerät unabhängig vom Computer die echten Daten auf seinem Bildschirm zeigt, fällt Manipulation vor dem Bestätigen auf. Der Private Key verlässt das Gerät nicht. Die Schwachstelle traf stattdessen den Prüfpfad: Der Schlüssel blieb sicher, die Firmware unangetastet, trotzdem konnte am Ende eine andere Zustimmung erteilt werden als die, die man gelesen hatte. Wenn das Display nicht mehr als verbindliche Referenz taugt, verliert eine Hardware-Wallet in diesem Punkt ihren entscheidenden Vorteil gegenüber einer Software-Wallet auf einem infizierten Rechner. Technischer Kern: Race Condition und APDU Eine Race Condition ist ein Fehler, bei dem das Ergebnis davon abhängt, welcher von zwei nahezu gleichzeitig eintreffenden Befehlen zuerst verarbeitet wird. Der Code kann dabei in den meisten Fällen korrekt wirken; der Fehler zeigt sich, wenn jemand die Reihenfolge gezielt provoziert. APDU ist das Befehlsformat, über das Smartcards und Hardware-Wallets mit dem verbundenen Computer kommunizieren. Ein Signaturvorgang besteht aus mehreren solcher Kommandos. Die Ethereum-App führte dabei einen Zustand mit, der festhielt, welche Transaktion gerade geprüft wird. Dieser Zustand konnte überschrieben werden, während die Prüfung noch lief. Zwei Befehle parallel, kein eindeutiger Zustand: so entsteht die Race Condition. WebHID im Browser: warum eine Website überhaupt mit dem Gerät spricht WebHID ist eine Browser-Schnittstelle, über die Websites nach ausdrücklicher Freigabe direkt mit einem angeschlossenen USB-Gerät kommunizieren können. Ohne WebHID wäre die komfortable Nutzung von Hardware-Wallets in vielen dApps kaum möglich. Mit WebHID rückt die Website näher an das Gerät, als vielen Nutzern bewusst ist. Der beschriebene Angriff setzt voraus, dass man einer manipulierten oder gekaperten Website bereits WebHID-Zugriff gewährt hat und dort eine Transaktion anstößt. Ein Gerät, das unverbunden in der Schublade liegt, lässt sich nicht aus der Ferne angreifen. Der Kreis potenziell Betroffener ist dadurch kleiner, bleibt aber relevant: Wer regelmäßig DEXs, Bridges oder Staking-Oberflächen nutzt, erteilt diese Zugriffe häufig. Warum Approvals das größere Risiko sind Der Schaden entsteht in solchen Fällen oft nicht durch einen vertauschten Transfer, sondern durch das, was stattdessen unterschoben werden kann. Ein Token-Approval ist die Erlaubnis für einen Smart Contract, künftig Token bis zu einer bestimmten Menge (oder unbegrenzt) ohne erneute Bestätigung abzubuchen. Viele Anwendungen fordern aus Bequemlichkeit unbegrenzte Freigaben. Ein einmal erteiltes Approval läuft nicht automatisch ab und gilt, bis es aktiv widerrufen wird. Transfer vs. (unbegrenztes) Approval Ein Transfer kostet genau den Betrag, den man bestätigt. Ein unbegrenztes Approval kann im Worst Case den gesamten Token-Bestand betreffen, zu einem Zeitpunkt der Gegenseite. Darum ist es für Angreifer besonders attraktiv, eine kleine Überweisung durch eine weitreichende Freigabe zu ersetzen. Update auf Ethereum-App 1.22.2: so geht es in Ledger Live Version 1.22.2 schließt den beschriebenen Angriffsweg mit zwei Mechanismen: Die App akzeptiert keine neue Signiersitzung, solange eine Prüfung läuft, und sie weist eine eingehende Bestätigung zurück, wenn der interne Zustand nicht mehr zu dem passt, was angezeigt wurde. In der Release-Übersicht der Ethereum-App bei Ledger ist die Version geführt; dort wird lediglich "Security fixes" genannt, ohne Details. Das Update ist unkompliziert: Gerät verbinden, in Ledger Live den Manager für installierte Apps öffnen und die Ethereum-App aktualisieren. Bestände sind davon nicht betroffen, weil die Schlüssel aus der Recovery Phrase abgeleitet werden und nicht in der App gespeichert sind. Auch Deinstallation und Neuinstallation kosten keine Coins. So erkennen Sie die installierte Version Ledger Live zeigt im Gerätemanager zu jeder App die Versionsnummer. Steht dort 1.22.2 oder höher, ist der Fix aktiv. Steht dort 1.22.1 oder älter, fehlt er. Die Versionsnummer von Ledger Live selbst genügt nicht. Warum ein Firmware-Update die Ethereum-App nicht automatisch aktualisiert Firmware, Ledger Live und die einzelnen Coin-Apps werden getrennt gepflegt und separat aktualisiert. Wer nur die Firmware aktualisiert und sich damit in Sicherheit wiegt, kann dennoch eine veraltete Ethereum-App auf dem Gerät haben. Diese Trennung erklärt auch, warum Berichte zu Wallet-Sicherheitsfällen oft aneinander vorbeigehen: Beim Coldcard-Fall lag das Problem bei der Seed-Erzeugung; bei BitBox betrafen Schwachstellen die Firmware. Hier liegt der Fehler eine Ebene höher in einer austauschbaren App, daher reicht ein App-Update. Eine neue Recovery Phrase ist in diesem Fall nicht nötig. Nach dem Update: alte Token-Freigaben prüfen und widerrufen Das Update schützt künftige Signaturen, bereinigt aber nicht automatisch, was in der Vergangenheit freigegeben wurde. Wer in den letzten Monaten dApps genutzt hat, sollte die offenen Approvals der eigenen Adresse überprüfen. Block-Explorer und spezialisierte Tools zeigen, welche Contracts welche Token bewegen dürfen. Freigaben für nicht mehr genutzte Contracts lassen sich einzeln widerrufen. Ein Widerruf ist eine normale On-Chain-Transaktion und kostet Netzwerkgebühren. Praktisch ist es, die Bereinigung in Phasen niedriger Gebühren durchzuführen. Ein Nebeneffekt: Jeder Widerruf erscheint in der Transaktionshistorie und erzeugt Gebühren. Wer seine Bewegungen sauber dokumentiert, hat es bei der nächsten Steuererklärung leichter; gängige Steuer- und Portfolio-Tools importieren solche Ereignisse automatisch. Streit um die Offenlegung: Ledger vs. TestMachine Zum Ablauf existieren zwei Darstellungen, die nicht übereinstimmen; beide werden hier als Position der jeweiligen Partei wiedergegeben und sind nicht unabhängig bestätigt. Ledgers CTO Charles Guillemet erklärte, das interne Security-Lab Ledger Donjon habe den Fehler selbst gefunden, der Fix sei rund zwei Wochen vor der Veröffentlichung ausgeliefert worden. TestMachine habe sich erst danach über das Bug-Bounty-Programm gemeldet. Die Aussagen der Sicherheitsfirma stellte er als Angstmache zur Aufmerksamkeitserzeugung dar. TestMachine hält dagegen, das eigene Testsystem "Azimuth" habe die Schwäche in einem automatisierten Lauf auf einem Ledger Flex entdeckt, die Ergebnisse seien an Ledger weitergegeben worden. Zum Zeitpunkt der Veröffentlichung habe aus Sicht der Firma noch kein Fix bereitgestanden. Prüfbare Eckdaten liegen dazwischen: Der Changelog-Eintrag für 1.22.2 trägt das Datum 12. August 2026, der signierte Tag im Quellcode-Repository den 13. August. Als veröffentlichte Release-Version wurde sie allerdings erst um den 24. August sichtbar, zeitgleich mit der Analyse der Sicherheitsfirma. Wer in der Zwischenzeit prüfen wollte, ob ein Fix existiert, konnte ihn dort nicht finden. Eine technische Rekonstruktion der Abfolge inklusive Daten wurde von CryptoSlate zusammengestellt. Gab es bereits Verluste? Auf Basis der bisher von beiden Seiten vorgelegten Informationen gibt es keinen bestätigten Fall, in dem die Schwachstelle tatsächlich ausgenutzt wurde. Dokumentierte Verluste liegen nicht vor; das Auslesen privater Schlüssel war über diesen Weg ohnehin nicht möglich. Das ist eine gute Nachricht mit Einschränkung: Eine auf diese Weise erlangte Signatur sähe on-chain aus wie jede freiwillige Unterschrift. Betroffene würden den Vorfall vermutlich erst bemerken, wenn später Token abfließen, und ihn dann eher gewöhnlichem Phishing zuschreiben. Aus fehlenden bestätigten Fällen folgt daher nicht mit Sicherheit, dass es keine gab. Was der Fall über Hardware-Wallets und Self-Custody zeigt Aus dem Vorfall eine generelle Absage an Hardware-Wallets abzuleiten, wäre falsch. Der Angriff erforderte bereits erteilten Gerätezugriff und eine bösartige Anwendung, der Private Key blieb unangetastet, und die Lücke ist behoben. Die sinnvolle Lehre ist eine andere: Eine Hardware-Wallet verlagert Vertrauen vom Computer auf ein kleines Gerät mit eigenem Bildschirm. Dieses System besteht aus Firmware, Apps und Begleitsoftware, die separat gewartet werden. Sicherheit ist hier kein Zustand beim Kauf, sondern laufende Pflege: Apps aktuell halten, Approvals regelmäßig aufräumen und bei größeren Beständen eine zusätzliche Bestätigungsebene einplanen. Was Sie jetzt konkret tun sollten 1) Version prüfen und aktualisieren: Gerät verbinden, in Ledger Live den Gerätemanager öffnen und die Ethereum-App prüfen. Alles unter 1.22.2 aktualisieren. Ein reines Firmware-Update reicht nicht. 2) Offene Token-Approvals aufräumen: Prüfen, welche Contracts über Ihre Token verfügen dürfen, und alles widerrufen, was nicht mehr benötigt wird. 3) Bewegungen dokumentieren: Widerrufe und Umschichtungen erzeugen Gebühren und erscheinen in der Historie. Besser fortlaufend festhalten statt später rekonstruieren; Steuer- und Portfolio-Tools übernehmen oft den Import. (Stand: 25. August 2026. Dieser Artikel stellt keine Anlageberatung dar. Preise und Gebührenstrukturen können sich ändern; Konditionen vor dem Kauf beim Anbieter prüfen.)