Aktualisiert am 3. November 2026.
BTCPay Server hat Version 2.4.1 und ältere Ausgaben als Ziel der am 1. November gemeldeten Hot-Wallet-Diebstähle identifiziert. Im Hinweis vom 2. November empfiehlt das Projekt den betroffenen Betreibern eine neue Maschine und eine neue Wallet, auch wenn sie ihre Software inzwischen aktualisiert haben.
Die entscheidende Abgrenzung: Eine geschlossene Sicherheitslücke entzieht einem Angreifer nicht automatisch bereits erlangten Zugriff. Ein unveränderter Kontostand schließt eine frühere Kompromittierung nicht aus. Die Reaktion hängt deshalb von der zum Warnzeitpunkt laufenden Version ab, nicht nur von der heute angezeigten Nummer.
BTCPay Server: Welche Installationen betroffen sind
Der offizielle Hinweis vom 2. November nennt Server mit Version 2.4.1 vom 23. Juli oder älter. Laut Team nutzten die Angreifer eine andere Methode, um eine bereits in Version 2.4.2 vom 7. August korrigierte Schwachstelle auszunutzen. Ein Fehler im Bitcoin-Protokoll wird damit nicht beschrieben.
Bei Servern, die zum Zeitpunkt der Warnung am 1. November bereits Version 2.4.2 oder neuer ausführten, hat das Projekt nach eigenen Angaben keine Auswirkungen dieser Angriffe beobachtet. Diese Aussage ist auf die beschriebene Untersuchung begrenzt. Sie garantiert keine allgemeine Sicherheit gegenüber anderen Schwachstellen oder künftigen Angriffen.
| Situation | Hinweis des Projekts |
|---|---|
| 2.4.2 oder neuer schon vor der Warnung | Keine beobachteten Auswirkungen dieser Angriffe |
| 2.4.1 oder älter | Neuer Server und neue Wallet, auch ohne sichtbaren Diebstahl |
| Alte Version erst nach der Warnung aktualisiert | Empfehlung zum Neuaufbau bleibt bestehen |
| Diebstahl oder unbefugter Zugriff | Maschine und zugängliche Geheimnisse als kompromittiert behandeln |
Warum ein Update keine Bereinigung ersetzt
Ein Update korrigiert den vom Projekt bereitgestellten Code. Es beweist nicht, dass ein gestohlenes Passwort unbrauchbar geworden ist, eine unberechtigte Sitzung beendet wurde oder sämtliche Bestandteile der alten Maschine vertrauenswürdig sind. Wer Prävention und Wiederherstellung gleichsetzt, kann einen bereits erlangten Zugangsweg bestehen lassen.
Deshalb lautet die Empfehlung nicht, den kompletten alten Server auf einer Ersatzmaschine wiederherzustellen. Das Team verlangt eine frische Umgebung mit unterstützter Software und ersetzten Zugangsdaten. Beweismittel sollen dabei nicht pauschal gelöscht werden: Relevante Protokolle und Transaktionsunterlagen sind vor dem Austausch für die Untersuchung zu sichern.
Hot Wallets und außerhalb des Servers gehaltene Schlüssel
Eine Hot Wallet speichert die zum Ausgeben benötigten Schlüssel auf dem Server. Im beschriebenen Fall kann ein Zugriff auf die Maschine deshalb unmittelbar die Gelder gefährden. Unsere Erklärung zu Custodial- und Non-Custodial-Wallets trennt Schlüsselkontrolle, Online-Verbindung und betriebliche Verantwortung.
Laut Projekt waren Gelder mit außerhalb des Servers aufbewahrten Ausgabeschlüsseln, einschließlich Hardware-Wallets, von diesen Diebstählen nicht betroffen. Daraus folgt nicht, dass eine alte Installation mit externem Signiergerät vertrauenswürdig bleibt. Die Empfehlung, den alten Server neu aufzubauen, gilt auch dann, wenn die Wallet-Schlüssel anderswo gespeichert sind.
Eine neue Wallet benötigt ein neues Geheimnis
Der offizielle Ablauf beginnt mit einer auf einem vertrauenswürdigen Gerät erstellten Wallet und einem neuen Seed. Verbleibende Hot-Wallet-Gelder sollen dorthin übertragen werden. Wer den alten Seed auf dem neuen Server weiterverwendet, lässt die Gelder bei einer früheren Offenlegung gefährdet; eine neue Empfangsadresse ist nicht automatisch ein unabhängig erzeugtes neues Geheimnis.
Unser Beitrag zur Seed-Phrase und ihrem Schutz erklärt diesen Unterschied. Der alte Seed gehört weder in eine Wiederherstellungswebsite noch in eine Nachricht an angebliche Helfer. Der Sicherheitshinweis untersagt ausdrücklich die Weitergabe von Seed-Phrasen, privaten Schlüsseln, Passwörtern und anderen Zugangsdaten, auch an das Sicherheitsteam.
Nach Schutz der verbleibenden Gelder und Sicherung der Beweise soll der alte Server offline genommen und eine saubere virtuelle Maschine eingerichtet werden. Möglicherweise offengelegte Zugangsdaten müssen von einem vertrauenswürdigen Gerät aus widerrufen und ersetzt werden. Ihre Nachfolger auf der verdächtigen Maschine einzugeben, würde die beabsichtigte Trennung unterlaufen.
Version 2.4.7 ändert die Vorgeschichte nicht
Eine Kopie für die Untersuchung aufzubewahren ist etwas anderes, als sie wieder produktiv einzusetzen. Vor dem Austausch müssen notwendige Wiederherstellungsunterlagen erhalten bleiben, ohne das einzige vorhandene Exemplar zu verlieren. Daraus entsteht jedoch keine Sicherheit für die erneute Verwendung möglicherweise offengelegter Seeds oder Zugangsdaten.
Die offiziellen Versionshinweise zu 2.4.7 vom 29. Oktober beschreiben weitere Sicherheits-, Zuverlässigkeits- und Zahlungsabrechnungskorrekturen. Sie zeigen eine verfügbare Aktualisierung, beweisen aber nicht, dass eine bis November verwundbare Maschine zuvor niemals angegriffen wurde.
Eine neue Softwareversion und eine Vorfallreaktion beantworten unterschiedliche Fragen: Welcher Code gehört auf den Server, und wie ist mit einer bereits verdächtigen Umgebung umzugehen? Bei fremdverwalteten Installationen verweist das Projekt auf den Hostinganbieter zur Unterstützung beim Umzug auf eine frische VM. CryptoRoad hat keine Leserinstallation aktualisiert, Gelder übertragen oder Angriffstests durchgeführt.
Für die Bestandsaufnahme reicht deshalb die aktuelle Anzeige allein nicht aus. Hilfreich sind auch der Zeitpunkt des letzten Updates und die davor verwendete Version. Ein nach der Warnung eingespieltes Paket beseitigt die frühere Exposition nicht rückwirkend; genau deshalb trennt der Hinweis den damaligen Zustand von dem heute sichtbaren Softwarestand.
Veröffentlichte Adressen belegen keine vollständige Schadenssumme
BTCPay Server nennt gemeldete Zieladressen, warnt aber vor möglicherweise älteren Aktivitäten an diesen Adressen. Guthaben und Transaktionsverläufe ergeben deshalb keine bestätigte Gesamtsumme des Schadens. Wir ordnen nicht jede Übertragung diesem Vorfall zu und versprechen weder Rückzahlung noch eine sichere Wiederbeschaffung der gestohlenen Gelder.
Eine brauchbare Meldung enthält die frühere Version, Uhrzeiten samt Zeitzone und öffentliche Transaktionsreferenzen; Geheimnisse müssen aus Protokollen entfernt werden. Bei Diebstahl empfiehlt das Projekt zusätzlich eine Anzeige bei den örtlichen Behörden. Entscheidend sind die historische Exposition und eine wieder vertrauenswürdige Umgebung, nicht allein eine aktuelle Versionsnummer.
