Die Entwickler des Bitcoin-Wallets Electrum haben eine als hoch eingestufte Electrum Sicherheitslücke geschlossen, die bereits aktiv ausgenutzt wurde. Bösartige Server konnten eine gerade gesendete Transaktion abfangen, im Wallet durch eine gefälschte ersetzen und Nutzer dazu bringen, beim Erhöhen der Gebühr per Replace-by-Fee (RBF) eine Zahlung an den Angreifer zu signieren. Mindestens ein Nutzer hat dabei Geld verloren. Die Lösung ist Version 4.8.3, die am 24. Oktober 2026 erschienen ist.
Dieser Beitrag erklärt sachlich, wie der Angriff funktioniert, wer betroffen ist und was du jetzt tun solltest.
Key Takeaways
- Betroffen sind alle Electrum-Versionen vor 4.8.3. Die Entwickler stufen die Lücke als „High“ ein.
- Laut Advisory führen einige Server den Angriff bereits „in the wild“ aus. Es gab zwei Meldungen, ein Nutzer hat Geld verloren.
- Der Trick: Der Server versteckt die echte Transaktion und zeigt eine gefälschte mit der Adresse des Angreifers an. Wer dann die Gebühr erhöht, signiert eine gültige Zahlung an den Angreifer.
- Version 4.8.3 prüft jetzt die Signaturen eigener Inputs in unbestätigten Transaktionen.
- Nicht betroffen ist, wer sich nur mit vertrauenswürdigen Servern verbindet, etwa einem eigenen.
Was über die Electrum Sicherheitslücke bekannt ist
Electrum ist ein sogenanntes Light Wallet: Es lädt nicht die gesamte Blockchain, sondern holt Transaktionsdaten von externen Servern. Bestätigte Transaktionen prüft der Client selbst per Simple Payment Verification (SPV). Bei unbestätigten Transaktionen im Mempool sieht das anders aus. In der offiziellen Electrum-FAQ heißt es dazu ausdrücklich, dass der Server bei unbestätigten Transaktionen vertrauenswürdig sein muss. Das ist dokumentiertes Design und kein neues Geheimnis.
Neu ist, dass jemand einen praktischen Weg gefunden hat, dieses Vertrauen auszunutzen. Das Sicherheits-Advisory GHSA-6jp4-8v48-cc5v beschreibt den Ablauf in vier Schritten:
- Der Nutzer sendet eine neue Transaktion (im Advisory „tx1“). Der bösartige Server, mit dem der Client als Hauptserver verbunden ist, leitet sie nicht weiter, sondern „schluckt“ sie.
- Stattdessen schickt der Server dem Wallet eine widersprüchliche Transaktion („tx2“), in der die Ausgänge durch die Adresse des Angreifers ersetzt sind.
- tx2 hat ungültige Signaturen. Das fiel bisher nicht auf, weil der Light Client diese Signaturen nicht geprüft hat. Das Wallet zeigt tx2 als unbestätigt an, die echte tx1 erscheint nicht.
- Erhöht der Nutzer nun manuell die Gebühr von tx2 per RBF, signiert Electrum eine neue, diesmal gültige Version mit höherer Gebühr. Das Geld geht an den Angreifer.
Der entscheidende Punkt: Die gefälschte Transaktion allein kann kein Geld bewegen, weil ihre Signaturen ungültig sind. Gefährlich wird sie erst, wenn der Nutzer sie selbst neu signiert. Genau darauf zielt der Angriff.
Wie die Angreifer ihre Spuren tarnen
Das Advisory nennt einige Details aus den beiden Meldungen, die zeigen, wie gezielt die Angreifer vorgehen:
- Passende Adressenden: In beiden Fällen war die Adresse des Angreifers so erzeugt, dass ihre letzten vier Zeichen mit denen der echten Zieladresse übereinstimmten. Wer nur kurz auf das Ende der Adresse schaut, bemerkt den Tausch nicht.
- Keine Gebühr: Nach der Schilderung des zweiten Nutzers hatte der Server die gefälschte Transaktion ohne Gebühr erstellt. Die Entwickler vermuten, dass die Zahlung so „hängen“ und den Nutzer zum Erhöhen der Gebühr verleiten sollte.
- Zurückgehaltene Transaktion: Der erste Nutzer berichtete, dass seine echte Transaktion nicht im Bitcoin-Netzwerk ankam. Der Server hatte sie also zurückgehalten.
Laut einem Bericht von CoinDesk betraf die erste Meldung ein 2-von-3-Multisig-Wallet mit zwei Hardware-Wallets, auf denen der Nutzer die echte Zahlung geprüft hatte. Er bemerkte später eine andere ausgehende Transaktion im Verlauf, meldete aber keinen Verlust. Wie viel der zweite Nutzer verloren hat und welche Server beteiligt sind, haben die Entwickler nicht veröffentlicht. Hardware-Wallets schützen in diesem Szenario übrigens nur, wenn man beim Signieren der Gebührenerhöhung die angezeigte Zieladresse vollständig mit der beabsichtigten vergleicht.
Zeitlinie der Offenlegung
Das Advisory dokumentiert den Ablauf genau:
- 11. Oktober 2026: Der erste Nutzer meldet das Problem vertraulich. Der Angriffsweg über die Gebührenerhöhung wird da noch nicht erkannt.
- 18. Oktober 2026: Der zweite Nutzer (Raju-K12) meldet, dass er nach einer Gebührenerhöhung Geld verloren hat.
- 23. Oktober 2026: Version 4.8.3 mit dem Fix wird im Git-Repository getaggt.
- 24. Oktober 2026: Die Programmdateien von 4.8.3 erscheinen, gleichzeitig wird die Lücke öffentlich gemacht.
Zwischen der Meldung des Verlusts und dem Fix lagen also sechs Tage. Das ist für ein Open-Source-Projekt zügig.
Was Version 4.8.3 ändert und wo Grenzen bleiben
Laut Advisory prüft der Client jetzt die Signaturen aller Inputs, die zum eigenen Wallet gehören („is_mine“), bevor er eine unbestätigte Transaktion in den lokalen Verlauf übernimmt. Eine gefälschte ausgehende Zahlung mit ungültigen Signaturen wird damit nicht mehr angezeigt. Die Release Notes zu Electrum 4.8.3 führen die Lücke als „sev-high“ und nennen neben diesem Fix weitere Sicherheitskorrekturen nach Meldungen von insgesamt vier Hinweisgebern, ohne diese im Detail zu beschreiben.
Die Entwickler sind offen, was der Fix nicht leistet:
- Geprüft werden nur Inputs aus eigenen Adressen. Eingehende unbestätigte Transaktionen werden weiterhin nicht validiert.
- Dem Client fehlt eine vollständige Konsens-Engine. Um auch fremde Inputs zu prüfen, müsste er unbestätigte Vorgänger-Transaktionen rekursiv bis zu bereits geschürften Transaktionen zurückverfolgen.
- Bereits geschürfte Transaktionen prüft Electrum wie bisher per SPV.
Praktisch heißt das: Eine unbestätigte eingehende Zahlung, die ein Light Wallet anzeigt, ist kein Beweis, dass das Geld wirklich kommt. Das galt schon immer, wird durch diesen Fall aber wieder deutlich.
Was Electrum-Nutzer jetzt tun sollten
- Update auf 4.8.3: Das ist die wichtigste Maßnahme. Lade die neue Version nur von der offiziellen Seite und prüfe die Signatur der Datei, wie es das Projekt empfiehlt.
- Jede Signatur prüfen: Bis zum Update rät das Advisory, bei jeder Transaktion, ob Gebührenerhöhung oder nicht, Zieladressen und Beträge vollständig zu kontrollieren. Nicht nur die letzten Zeichen.
- Misstrauen bei „hängenden“ Zahlungen: Taucht im Verlauf eine Transaktion auf, die du so nicht erstellt hast, oder hängt eine Zahlung ohne Gebühr, solltest du die Gebühr nicht erhöhen, sondern zuerst die Ausgänge prüfen und einen Block-Explorer gegenchecken.
- Eigenen Server nutzen: Wer Electrum mit einem eigenen oder vertrauenswürdigen Server verbindet, ist laut Advisory nicht betroffen. Für größere Beträge lohnt sich ein eigener Node mit Electrum-Server.
Einordnung
Der Fall zeigt ein bekanntes Muster: Ein Kompromiss aus dem Design wird so lange toleriert, bis jemand einen praktischen Angriff findet. Electrum hat das Vertrauen in den Server bei unbestätigten Transaktionen nie verschwiegen. Der Angriff funktionierte aber erst durch eine Kombination aus zurückgehaltener Transaktion, gefälschter Anzeige, ähnlicher Adresse und dem Komfort der Gebührenerhöhung. Am Ende bleibt der Mensch das letzte Prüfglied.
Ähnliche Muster haben wir zuletzt öfter gesehen: beim Ledger Hardware-Wallet Hack mit manipulierten Geräten, beim Qubic Hack durch schwache Wallet-Seeds und bei der zehn Jahre alten Sicherheitslücke im XRP Ledger. Die Lehre ist jedes Mal ähnlich: Software aktuell halten und vor dem Signieren genau hinsehen.
Fazit
Die Electrum Sicherheitslücke ist ernst, weil sie bereits ausgenutzt wurde und Geld gekostet hat. Sie ist aber auch gut beherrschbar: Mit Version 4.8.3 werden gefälschte ausgehende Transaktionen erkannt, und wer jede Zieladresse vollständig prüft, kann den Trick auch ohne Update durchschauen. Wer Electrum nutzt, sollte heute aktualisieren. Wir halten dich auf dem Laufenden, falls weitere Details zu den Angreifern oder zur Schadenshöhe bekannt werden.
