BTCPay Server: Angreifer leeren Hot Wallets auf Instanzen bis Version 2.4.1
Das Projekt BTCPay Server meldet Diebstähle aus Hot Wallets auf Instanzen mit Version 2.4.1 oder älter. Die ersten Berichte kamen am 1. November 2026. Genutzt wird die Lücke, die Version 2.4.2 im August geschlossen hat. Wer alt unterwegs war, soll laut Projekt auf einen frischen Server mit neuer Wallet umziehen, auch ohne sichtbaren Verlust.
Das Open-Source-Projekt BTCPay Server hat am 2. November 2026 einen Vorfallbericht veröffentlicht: Angreifer stehlen Bitcoin und Litecoin aus Hot Wallets auf selbst betriebenen Instanzen mit Version 2.4.1 oder älter. Die ersten Meldungen gingen am 1. November ein.
Für Server, die schon vor der Warnung vom 1. November auf 2.4.2 oder neuer liefen, hat das Projekt bisher keine Auswirkungen festgestellt. Für alle älteren Server gilt: Guthaben in eine neue Wallet retten, Server vom Netz nehmen und neu aufbauen, denn ein Update allein genügt nicht.
Was ist passiert?
Laut Zeitleiste des Projekts fand ein in den Meldungen beschriebener Abfluss am 1. November um 13:46 Uhr UTC statt, die erste Meldung per E-Mail kam um 20:56 Uhr UTC. Um 22:25 Uhr UTC warnte das Projekt öffentlich und bat Betreiber, ihre Server abzuschalten. Hoster wie LunaNode nahmen Instanzen vorsorglich vom Netz. Am 2. November grenzte das Projekt die Betroffenheit auf 2.4.1 und älter ein.
Technisch nutzen die Täter nach Angaben des Projekts die Schwachstelle, die Version 2.4.2 am 7. August geschlossen hat, allerdings mit einer anderen Methode. Schon im August hatte das Projekt Diebstähle über diese Lücke bestätigt, damals über LND-Zugangsdaten. Mit der kritischen Lücke, wegen der am 29. Oktober das Notfall-Update 2.4.7 erschien, hat das nichts zu tun. Details zur Technik und eine CVE-Nummer nennt der Bericht nicht.
Wer ist betroffen?
Betroffen sind Betreiber eigener BTCPay-Server mit Version 2.4.1 (vom 23. Juli 2026) oder älter, die Schlüssel als Hot Wallet auf dem Server halten. Die Version steht nach der Anmeldung unten auf der Seite. Guthaben in Wallets, deren Schlüssel außerhalb des Servers liegen, etwa auf Hardware-Wallets, blieben laut Projekt verschont. Den Neuaufbau des Servers empfiehlt es trotzdem.
Wie kritisch ist das?
Das Risiko ist direkter Geldverlust. BleepingComputer berichtet, die Untersuchung habe sich darauf konzentriert, wie sich der Angreifer als Administrator anmelden konnte. Seit wann die aktuellen Angriffe laufen und wie hoch der Gesamtschaden ist, hat das Projekt nicht festgestellt. Das Projekt betont, dass ein unveränderter Kontostand einen früheren Angriff nicht ausschließt. Für 2.4.7 liegen ihm keine glaubwürdigen Berichte über geleerte Hot Wallets vor.
Was sollten Admins jetzt tun?
- Inventar: Version jeder Instanz prüfen. Server, die schon vor der Warnung auf 2.4.2 oder neuer liefen, sollten auf 2.4.7 aktualisiert werden.
- Guthaben sichern: Bei 2.4.1 oder älter auf einem vertrauenswürdigen Gerät eine neue Wallet mit neuem Seed anlegen und verbliebene Mittel dorthin überweisen. Das gilt auch, wenn erst nach der Warnung aktualisiert wurde.
- Abschalten: Alten Server vom Netz nehmen und vorher Logs sowie Transaktionsdaten für die Untersuchung sichern.
- Neu aufbauen: Frische VM mit aktueller Version aufsetzen und das alte System nicht vollständig zurückspielen.
- Zugänge tauschen: Von einem sauberen Gerät aus Hosting-, SSH-, API- und Lightning-Zugänge widerrufen und ersetzen.
- Melden: Vorfälle an das Projekt und die Polizei melden, dabei niemals Seed oder Schlüssel weitergeben.
Einordnung für Unternehmen
Das Projekt räumt ein, ältere Installationen nicht gut genug erreicht zu haben. Der Fall zeigt, wie schnell selbst gehostete Dienste mit Zugriff auf Geld zum Ziel werden, wenn Updates liegen bleiben. Das Projekt rät, auf dem Server nur die für den Betrieb nötigen Beträge zu halten und den Rest in eine Wallet mit externen Schlüsseln zu verschieben. Aus Sicht der Redaktion gehört für solche Dienste eine feste Update-Benachrichtigung in den Betriebsplan.
Passende Anleitungen auf S-EDV
- VPS absichern und härten: UFW, SSH-Schlüssel und Fail2Ban unter Ubuntu und Debian
- Erster eigener Cloud-Server: VPS bei Hetzner oder netcup aufsetzen und absichern
