Betreiber von BTCPay Server sollten ihre Installation jetzt prüfen: In der Nacht zum 2. November 2026 meldete das Open-Source-Projekt, dass Angreifer auf mehreren selbst gehosteten Instanzen die Hot Wallets leergeräumt haben. Nach dem aktuellen Stand der Untersuchung trifft es Server mit veralteter Software, konkret Version 2.4.1 vom 23. Juli 2026 oder älter. Für die aktuelle Version 2.4.7 liegen laut Projekt keine glaubwürdigen Berichte über abgezogene Guthaben vor.
Wie viele Händler betroffen sind und wie viel Bitcoin gestohlen wurde, ist offen. Auch technische Details zum Angriffsweg hat das Team noch nicht veröffentlicht. Ein ausführlicher Blogbeitrag ist angekündigt. Bis dahin stützt sich alles, was bekannt ist, auf Beiträge des Projekts und seines Gründers Nicolas Dorier auf X.
Was bei BTCPay Server passiert ist
Am 1. November um 23:25 Uhr MEZ schlug das Projekt Alarm. In einem Beitrag auf X hieß es, man erhalte Berichte, dass Hot Wallets auf BTCPay-Servern von unbefugten Angreifern „gesweept“ würden – also in einem Zug leergeräumt. Wer eine Instanz betreibe, solle sie mit dem Befehl ./btcpay-down.sh herunterfahren, bis die Untersuchung abgeschlossen sei. Zu diesem Zeitpunkt nannte das Team weder Versionen noch Schadenssummen.
Gut zwei Stunden später, gegen 01:30 Uhr MEZ, ergänzte Dorier erste Erkenntnisse. Die öffentlichen Server des Projekts, die auf Version 2.4.7 laufen, seien nicht angegriffen worden. Die eingegangenen Berichte beträfen offenbar Versionen vor 2.4.2. Der Angreifer habe sich auf den betroffenen Instanzen als Administrator angemeldet. Wie er an diesen Zugang kam, sei noch unklar.
Gegen 03:00 Uhr MEZ schrieb Dorier, es gebe Spuren, dass Schwachstellen aus der Zeit vor Version 2.4.2 ausgenutzt worden seien. Nach einer neuen Lücke sehe es nicht aus. Um 05:07 Uhr MEZ folgte die bislang konkreteste Mitteilung des Projekts: Die Incident-Response-Untersuchung habe einen Angriffsvektor identifiziert, der auf Instanzen mit Version 2.4.1 oder älter zielt. Für Nutzer der aktuellen Version 2.4.7 gebe es keine glaubwürdigen Berichte über geleerte Hot Wallets.
Einige Hosting-Anbieter haben ältere Instanzen nach der ersten Warnung offenbar automatisch abgeschaltet. Das Projekt bedankte sich ausdrücklich bei LunaNode und weiteren Hostern. Wer BTCPay Server über einen solchen Anbieter betreibt und seine Instanz plötzlich offline findet, sollte das zuerst prüfen.
Warum Hot Wallets besonders exponiert sind
BTCPay Server ist ein selbst gehosteter Zahlungsprozessor. Händler nehmen damit Bitcoin direkt in die eigene Wallet an, ohne Zahlungsdienstleister dazwischen. Optional lässt sich eine Hot Wallet einrichten. Dabei liegt die Seed-Phrase, also das Geheimnis, mit dem sich Coins ausgeben lassen, auf dem Server selbst. Das ist bequem, etwa für automatische Rückerstattungen und Auszahlungen, weil der Server Transaktionen ohne separates Gerät signieren kann.
Der Preis dafür: Wer den Server übernimmt, kann das Guthaben verschieben. Genau dieses Szenario beschreibt Dorier. Mit Admin-Zugang auf einer Instanz mit Hot Wallet hat ein Angreifer alles, was er braucht. Händler, die nur eine Watch-only-Wallet nutzen und Zahlungen mit einem Hardware-Wallet oder offline signieren, haben dieses Risiko in dieser Form nicht. Bei ihnen liegt kein Schlüssel auf dem Server.
Dorier formulierte die Lehre daraus deutlich: In eine Hot Wallet gehöre nicht mehr, als man zu verlieren bereit sei. Man könne nicht garantieren, dass so etwas nicht wieder passiere. Auf die Frage eines Nutzers, ob Betroffene nur die Seed-Phrase austauschen müssten, antwortete er, sie sollten den gesamten Server als kompromittiert betrachten.
Der Hintergrund: Lücke aus dem August und viele Sicherheitsupdates
BTCPay Server hatte bereits im August einen ernsten Vorfall. Version 2.4.2 vom 7. August schloss laut dem damaligen Sicherheitshinweis eine kritische Lücke, die bereits aktiv ausgenutzt wurde. Ein Angreifer konnte ohne Anmeldung Zugangsdateien (Macaroons) für LND-Lightning-Knoten abgreifen und damit Guthaben bewegen. Die On-Chain-Wallets von BTCPay Server, einschließlich Hot Wallets, waren davon laut Projekt nicht betroffen.
Ob der jetzige Angriffsweg mit dieser Lücke zusammenhängt, ist nicht bekannt. Das Projekt spricht nur von Schwachstellen aus der Zeit vor 2.4.2 und von einem Vektor gegen Version 2.4.1 und älter. Wir stellen hier keine Verbindung her, die das Team nicht selbst zieht.
Seit August hat das Projekt in kurzer Folge weitere Sicherheitsupdates veröffentlicht. Version 2.4.5 vom 6. Oktober blockiert unter anderem ausgehende Verbindungen in private Netze, um SSRF-Angriffe zu verhindern. Version 2.4.6 folgte am 26. Oktober. Die aktuelle Version 2.4.7 vom 29. Oktober behebt laut Release Notes 85 Befunde aus einem automatisierten Code-Scan von Anthropic: einen kritischen, 13 hohe, 52 mittlere und 19 niedrige. Ob einer davon mit den aktuellen Angriffen zu tun hat, sagt das Projekt nicht. Dorier betont, dass betroffene Systeme auf deutlich älteren Versionen liefen.
Was über den Angriff noch offen ist
- Umfang: Weder die Zahl der betroffenen Instanzen noch die Höhe des Schadens ist bekannt.
- Technik: Wie der Angreifer Admin-Rechte erlangte, hat das Projekt nicht veröffentlicht. Details sollen im angekündigten Blogbeitrag folgen.
- Versionen dazwischen: Das Projekt nennt 2.4.1 und älter als Ziel des Vektors. Dorier schrieb zudem, nach Sichtung aller Berichte sei niemand betroffen gewesen, der eine Version oberhalb von 2.4.2 nutzte. Eine formale Aussage zu jeder einzelnen Zwischenversion gibt es nicht.
- Täter: Dorier veröffentlichte Empfängeradressen des Angreifers, darunter eine Litecoin-Adresse. Eine Zuordnung zu einer Gruppe gibt es nicht.
Die Lage erinnert an andere Angriffe der vergangenen Tage, bei denen Infrastruktur rund um Krypto-Zahlungen im Fokus stand, etwa das DNS-Hijacking mehrerer DeFi-Websites. Der Unterschied: Bei BTCPay Server ist jeder Händler für seinen eigenen Server verantwortlich. Es gibt keinen zentralen Schalter, mit dem das Projekt alle Instanzen auf einmal schützen könnte – deshalb der Aufruf an jeden Betreiber, selbst herunterzufahren.
Was BTCPay-Server-Betreiber jetzt tun sollten
- Version prüfen: Die installierte Version steht im Footer des Admin-Bereichs. Alles unterhalb von 2.4.7 sollte aktualisiert werden, bei Standardinstallationen über Servereinstellungen, Wartung, Update.
- Bei Version 2.4.1 oder älter mit Hot Wallet: Den Server als kompromittiert behandeln. Restguthaben möglichst von einem sauberen Gerät aus in eine neue Wallet mit neuer Seed-Phrase verschieben, nicht in eine Wallet, deren Seed auf dem alten Server lag.
- Zugänge kontrollieren: Liste der Benutzer und Administratoren, API-Schlüssel und verbundene Dienste prüfen. Unbekannte Konten und Schlüssel entfernen, Passwörter und Zwei-Faktor-Einstellungen erneuern.
- Neu aufsetzen statt flicken: Wer Spuren eines fremden Admin-Logins findet, sollte die Instanz neu aufsetzen und Logs vorher sichern. Das Projekt bittet Betroffene, Informationen und Logs an sein Sicherheitsteam zu schicken.
- Hot Wallet klein halten: Nur so viel Guthaben auf dem Server lassen, wie für den Betrieb wirklich nötig ist. Größere Beträge gehören in eine Wallet, deren Schlüssel nie auf einem Internet-Server liegt.
- Regelmäßig updaten: Dorier rät ausdrücklich zu häufigen Updates. Wer seit 2.4.2 mindestens einmal aktualisiert hat, habe nach seiner Aussage keinen Grund zur Panik.
Wie wichtig Updates bei Wallet-Software sind, zeigte zuletzt auch die Electrum-Sicherheitslücke in Version 4.8.3. Und der Binance-Hack hat in der vergangenen Woche vorgeführt, dass Hot Wallets auch bei großen Börsen das bevorzugte Ziel sind.
Einordnung
Der Vorfall ist ärgerlich, aber er ist kein Beleg dafür, dass Bitcoin oder selbst gehostete Zahlungsabwicklung grundsätzlich unsicher wären. Nach allem, was bekannt ist, trifft er Server, die seit rund drei Monaten keine Updates erhalten haben – in einer Phase, in der das Projekt mehrere Sicherheitsversionen veröffentlicht hat. Self-Hosting bedeutet eben auch Self-Patching. Wer einen Server mit Schlüsselmaterial ins Internet stellt, muss ihn konsequent pflegen. Offen bleibt, ob der angekündigte Bericht des Projekts weitere betroffene Versionen oder einen anderen Einstiegsweg nennt. Bis dahin gilt: aktualisieren, Zugänge prüfen und Hot Wallets klein halten.
