BTCPay Server absichern: Warum das Update auf 2.4.4 deinen Lightning-Knoten allein nicht schützt

Kurz vorweg, weil es die Frage ist, die dich hergeführt hat: Das Update auf BTCPay Server 2.4.4 schließt den öffentlichen Standardweg zu deinem Lightning-Knoten. Eine Route, die du selbst gebaut hast, räumt es nicht weg. Wer die LND-Schnittstelle seines Servers irgendwann über einen eigenen Reverse Proxy nach außen gestellt hat, muss deshalb zwei Dinge erledigen: aktualisieren und diesen Zugang wieder entfernen. Das Projekt hinter BTCPay Server schreibt genau das in seiner Ankündigung vom 8. September 2026.

Der Anlass ist kein neuer Diebstahl. Das Projekt beobachtet, dass automatisierte Programme gezielt Server abklopfen, bei denen dieser Zugang von Hand wieder geöffnet wurde. Eine erfolgreiche Übernahme über diesen Weg ist bislang nicht gemeldet, und das Projekt stellt auch keine Verbindung zu den Tätern des Augustvorfalls her. Das ist die gute Nachricht an der Sache: Es gibt ein Zeitfenster, in dem sich das Problem ohne Schaden auflösen lässt.

Für dich als Halter oder Händler hängt daran mehr als ein Serverdetail. Ein selbst betriebener Zahlungsserver ist der Punkt, an dem eingehende Bitcoin-Zahlungen, die Schlüssel deines Lightning-Knotens und dein Betriebsguthaben zusammenlaufen. Wer dort den Zugriff verliert, verliert echtes Geld, nicht Konfiguration. Deshalb gehört auf denselben Schreibtisch die zweite Frage: Wie viel Guthaben muss überhaupt dauerhaft auf einem Knoten liegen, der am Netz hängt, und was gehört in die kalte Verwahrung? Wenn du diese Trennung noch nicht gezogen hast, ist unser Vergleich der Hardware-Wallets der bessere Startpunkt als jede weitere Proxy-Regel.

Was gerade passiert: Bots rufen einen ungeschützten LND-Endpunkt

Das Projekt beschreibt das Muster offen. Automatisierte Programme rufen wiederholt einen bestimmten Pfad der LND-Programmierschnittstelle auf: den Endpunkt zum Wechseln des Wallet-Passworts unter /lnd-rest/btc/v1/changepassword. Betroffen sind ausdrücklich Server, auf denen dieser Zugriff manuell wieder eingeschaltet wurde, nachdem BTCPay Server ihn im August standardmäßig abgeschaltet hatte.

Der Punkt, der die Sache heikel macht: Dieser Endpunkt verlangt keine Anmeldung, solange die LND-Wallet noch gesperrt ist. Das ist kein Fehler im engeren Sinn, sondern die Bauart der Schnittstelle. Eine gesperrte Wallet kann noch niemanden authentifizieren, also muss der Weg zum Entsperren und zum Passwortwechsel ohne Berechtigungsnachweis erreichbar sein. Solange dieser Weg nur innerhalb des Servers erreichbar ist, ist das unkritisch. Erst die Veröffentlichung ins offene Netz macht daraus ein Einfallstor.

Macaroon, LND und Reverse Proxy: die drei Begriffe, ohne die der Rest nicht trägt

LND ist eine der verbreiteten Umsetzungen des Lightning-Netzwerks, also der Zahlungsschicht, die Bitcoin-Überweisungen in Sekunden und für Bruchteile eines Cents abwickelt. Wenn dein BTCPay Server Lightning-Zahlungen annimmt, steckt in aller Regel LND darunter.

Ein Macaroon ist der Berechtigungsnachweis, mit dem LND Befehle zulässt. Man kann es sich als Schlüsseldatei mit abgestuften Rechten vorstellen. Das Admin-Macaroon ist der Generalschlüssel: Wer es hat, verfügt über die Wallet und die Zahlungskanäle des Knotens.

Ein Reverse Proxy ist der Server-Dienst, der eingehende Anfragen aus dem Internet entgegennimmt und an den richtigen internen Dienst weiterreicht. BTCPay Server bringt einen eigenen mit. Viele Betreiber haben daneben oder davor einen zweiten eingerichtet, um etwa eine Handy-Wallet von unterwegs mit dem eigenen Knoten sprechen zu lassen. Genau diese selbst gebaute Weiterleitung ist der Punkt, um den es hier geht.

Warum das Zeitfenster nach dem LND-Neustart überhaupt entsteht

Der Ablauf ist unspektakulär und deshalb so wirksam. Nach jedem Neustart von LND ist die Wallet zunächst gesperrt. BTCPay Server hat dafür eine interne Entsperrung, die das Passwort automatisch nachreicht. Zwischen dem Start des Dienstes und dem Moment, in dem diese Entsperrung greift, liegt eine kurze Spanne.

Ist die Schnittstelle in dieser Spanne aus dem offenen Netz erreichbar, kann ein Angreifer schneller sein. Das Projekt beschreibt die Folge nüchtern: Wer in diesem Moment das bekannte Passwort einreicht, kann ein neues setzen und sich von LND ein Admin-Macaroon ausstellen lassen, mit dem sich der Knoten steuern lässt. Ab da gehört der Generalschlüssel jemand anderem.

Verschlimmert hat das ein Detail aus der Vergangenheit: Ältere BTCPay-Installationen legten ihre LND-Wallets mit einem gemeinsamen Standardpasswort an. Es war also nichts zu raten. Wer wusste, wie die Voreinstellung lautet, musste nur im richtigen Moment anklopfen.

Der Diebstahl im August und die Sondierung im September sind zwei Vorgänge

Diese Trennung ist wichtig, weil die deutschsprachige Berichterstattung im August stehen geblieben ist und beide Ereignisse leicht zu einem einzigen verschwimmen.

Der ältere Vorgang, 7. August 2026. Das Projekt veröffentlichte einen Sicherheitshinweis zu Version 2.4.2. Alle vorherigen Fassungen enthielten eine Lücke, über die ein nicht angemeldeter Angreifer aus der Ferne die Macaroon-Dateien von LND abgreifen konnte. Das Projekt bestätigt ausdrücklich, dass die Lücke ausgenutzt wurde, dass Nutzer betroffen waren und dass Guthaben abgeflossen ist. Die eigenen On-Chain-Wallets von BTCPay Server waren davon nicht erfasst, auch die heißen nicht; Guthaben in der On-Chain-Wallet von LND gehört dagegen zum betroffenen Knoten. Später setzten das Projekt und Unterstützer eine Belohnung von zehn Prozent der wiederbeschafften Bitcoin aus, gedeckelt auf drei BTC, seinerzeit rund 190.000 Dollar.

Der neue Vorgang, 8. September 2026. Hier gibt es bisher keinen gemeldeten Schaden. Es geht um Bots, die einen Angriffsweg suchen, und um eine Vorsorgemaßnahme des Projekts. Wer beides vermischt, behauptet einen Verlust, den keine Quelle belegt.

Was das Update auf BTCPay Server 2.4.4 tatsächlich schließt

Das Projekt geht nach eigener Darstellung auf zwei Wegen gegen den beschriebenen Ablauf vor.

Erstens: Schluss mit dem gemeinsamen Passwort. Das neue LND-Abbild legt keine Wallets mehr mit einem geteilten Standardpasswort an. Jede neu erzeugte Wallet bekommt ein eigenes Zufallspasswort. Bestehende Wallets, die noch auf der alten Voreinstellung stehen, werden beim Start automatisch umgestellt. Damit fällt der Teil des Angriffs weg, der auf Vorwissen beruhte.

Zweitens: Sperren an der Netzwerkkante. Die Docker-Einrichtung blockiert die nicht authentifizierten Wege zum Einrichten und Entsperren der Wallet bereits im mitgelieferten Reverse Proxy. Über den öffentlichen Standardpfad ist das Neustartfenster damit zu.

Mit 2.4.4 kamen weitere Änderungen, die dich im Betrieb treffen können, auch wenn sie mit dem Angriff nichts zu tun haben. NFC-Zahlungen im Bezahlvorgang sind jetzt ab Werk abgeschaltet und müssen in den Shop-Einstellungen wieder eingeschaltet werden. Rechnungen ohne Betrag werden standardmäßig blockiert. Die Einrichtung von Boltcards über ein Kartenlesegerät am Rechner ist entfallen, stattdessen öffnet BTCPay Server die zugehörige App. Wer die WHMCS-Anbindung nutzt, braucht wegen einer nicht abwärtskompatiblen Änderung die Version 4.0.0 des Zusatzmoduls und einen neu erzeugten API-Schlüssel. Eingeladene Shop-Nutzer müssen ihre Einladung erst annehmen. Und im Kassenmodul ist die Möglichkeit entfallen, je Anfrage eine eigene Benachrichtigungsadresse zu übergeben; es gilt die im Modul hinterlegte.

Die Standard-Docker-Einrichtung hat zugleich einen größeren Sprung gemacht: Bitcoin Core wechselt von 29.2 auf 31.1, LND auf 0.21.3-beta. Die Unterstützung für Bitcoin Knots wurde entfernt, nachdem Knots laut Projekt einer Kette gefolgt ist, die sich von der Hauptkette abgespalten hat. Wer Knots bewusst einsetzt, sollte das vor dem Update lesen und nicht erst danach. Dazu kommt eine engere Anbindung an den Wirtsrechner: Statt breitem SSH-Zugriff bekommt der Anwendungsbehälter nur noch einen Schlüssel für eine kleine Liste freigegebener Verwaltungsbefehle.

Warum deine eigene Reverse-Proxy-Regel vom Update unberührt bleibt

Hier liegt der Kern, und es ist derselbe Satz, den das Projekt schon im August geschrieben hat: Ein Update von BTCPay Server schließt keine Zugangswege, die du getrennt davon verwaltest. Eine Weiterleitung in deinem eigenen Reverse Proxy, ein weitergeleiteter Port in der Fritzbox, ein selbst angelegter Tor-Dienst — all das kennt das Update nicht und kann es nicht zurücknehmen.

Die Anweisung des Projekts ist deshalb unmissverständlich: Stelle die LND-Schnittstelle nicht von Hand über einen eigenen Reverse Proxy ins Netz. Wenn du das bereits getan hast, entferne diesen Zugang und aktualisiere deinen Server. Beides, in dieser Reihenfolge lesbar, nicht als Alternative.

Wer schon im August über einen eigenen Weg exponiert war, sollte zusätzlich die Berechtigungsnachweise seines Knotens erneuern. Das Update auf 2.4.2 hat die Macaroons der Standardinstallation automatisch neu erzeugt; für selbst verwaltete Pfade gilt das nicht. Dieselbe Logik kennst du aus dem Fall der Core-Lightning-Schwachstelle von Ende August, den wir in dieser Analyse zur Core-Lightning-Lücke auseinandergenommen haben: Die gefährliche Annahme ist nie die Lücke selbst, sondern der Glaube, ein Versionssprung erledige alles Weitere.

Externer Lightning-Zugriff ist zurück, aber nur mit ausdrücklichem Opt-in

Für viele Betreiber war die Abschaltung im August schmerzhaft, weil damit auch der legitime Weg wegfiel: eine Handy-Wallet wie Zeus, die von unterwegs den eigenen Knoten bedient. Das Projekt hat das nie bestritten und im September einen geordneten Weg zurück angekündigt.

Der Stand heute: Eine Änderung an der Routensteuerung wurde am 11. September eingepflegt und bietet eine unterstützte Möglichkeit für den Fernzugriff, während die Schnittstellen von LND und Core Lightning ab Werk abgeschaltet bleiben. Das ist der entscheidende Unterschied zur alten Lage: Der Zugriff ist vorhanden, aber du musst ihn bewusst einschalten, und er läuft dann über den vom Projekt gepflegten Pfad statt über deine Handarbeit.

Für dich heißt das praktisch: Wenn du Fernzugriff brauchst, nimm den vorgesehenen Schalter und baue keine eigene Weiterleitung mehr. Und prüfe bei der Gelegenheit, welche Wallet auf deinem Telefon überhaupt Zugriff auf deinen Knoten haben soll. Welche Software-Wallets dabei welche Verbindungsarten unterstützen, steht im Software-Wallet-Vergleich, den du unten verlinkt findest; nicht jede bringt dieselben Berechtigungsstufen mit, und ein Fernzugriff mit eingeschränktem Macaroon ist deutlich harmloser als einer mit dem Generalschlüssel.

Die Prüfliste für Betreiber: Was du heute abarbeitest

Der Reihe nach, und zwar ganz gleich, ob du dich betroffen fühlst:

1. Version feststellen. Die laufende Fassung steht in der Fußzeile des Administrationsbereichs. Steht dort etwas unterhalb von 2.4.4, ist das dein erster Handgriff.
2. Aktualisieren. Bei einer Docker-Installation über Server Settings › Maintenance › Update. Bei einer anders verwalteten Installation über deinen gewohnten Weg.
3. Eigene Weiterleitungen suchen. Geh deine Proxy-Konfiguration durch und halte nach jeder Regel Ausschau, die etwas unterhalb von /lnd-rest/ nach außen reicht. Denk dabei auch an weitergeleitete Ports im Router und an selbst angelegte Tor-Dienste.
4. Gefundene Wege entfernen. Nicht kommentieren und liegen lassen, sondern herausnehmen und den Dienst neu laden.
5. Berechtigungen erneuern, falls dein Knoten über einen selbst verwalteten Pfad erreichbar war. Neue Macaroons erzeugen, alte ungültig machen, hinterlegte Verbindungen in Handy-Wallets neu aufsetzen.
6. Fernzugriff neu aufsetzen, falls du ihn brauchst, über die vorgesehene Einstellung statt über eigene Regeln.

Wenn dir die Zeit fehlt, den dritten und vierten Punkt sauber zu erledigen, gilt der Rat aus dem Augusthinweis sinngemäß weiter: Ein Knoten, der nicht erreichbar ist, kann auch nicht abgeklopft werden. Lieber ein paar Stunden ohne Fernzugriff als ein offener Endpunkt übers Wochenende.

Woran du erkennst, ob dein LND-Knoten kompromittiert wurde

Das Projekt hat für den Augustvorfall eine Prüfroutine veröffentlicht, die auch hier trägt. Schau in deinem Knoten nach Zahlungen, die du nicht veranlasst hast. Achte auf Kanalschließungen, die du nicht angestoßen hast, und auf Gegenstellen, die dir unbekannt sind. Gleiche dein On-Chain-Guthaben und deine Kanalsalden mit deinen eigenen Aufzeichnungen ab. Alles, was du dir nicht erklären kannst, ist ein Grund weiterzusuchen, nicht ein Grund zu beruhigen.

Ein Hinweis zur Einordnung, damit hier keine Panik entsteht: Eine Übernahme über den im September beobachteten Weg ist bislang von niemandem gemeldet worden. Die Prüfung ist Sorgfalt, keine Schadensaufnahme.

Getrennt davon zu betrachten ist ein dritter Vorfall, den das Projekt in derselben Mitteilung offenlegt: Der selbst betriebene Server für den Bau von Zusatzmodulen wurde kompromittiert, entdeckt am 2. September. Betroffen sind nach Darstellung des Projekts ausschließlich Entwickler von Zusatzmodulen, nicht deren Nutzer. Veröffentlichte Module wurden nach Prüfung nicht durch bösartige Fassungen ersetzt, alle Zugangstoken wurden erneuert. Hinterlegte E-Mail-Adressen waren wahrscheinlich einsehbar; wer dort registriert ist, sollte in den nächsten Wochen mit Phishing-Versuchen rechnen und unerwartete Nachrichten entsprechend behandeln.

Was der Vorfall für deutsche Händler mit Bitcoin-Zahlung bedeutet

BTCPay Server ist in Deutschland vor allem bei kleinen Händlern, Handwerksbetrieben, Vereinen und Onlineshops im Einsatz, die Bitcoin ohne Zwischenhändler annehmen wollen. Der Reiz liegt darin, dass die Zahlung direkt in die eigene Wallet geht. Es gibt keinen Dienstleister, der das Guthaben zwischenzeitlich hält.

Diese Bauart hat eine Kehrseite, die der aktuelle Fall vorführt: Wo niemand zwischengeschaltet ist, gibt es auch niemanden, der haftet, sperrt oder erstattet. Bei einem verwahrenden Anbieter wäre ein Angriff sein Problem. Bei deinem eigenen Server ist er deiner. Die Verantwortung für Updates, für Zugriffswege und für die Aufteilung zwischen Betriebsguthaben und Rücklage liegt vollständig bei dir.

Daraus folgt eine schlichte Betriebsregel, die unabhängig von jeder einzelnen Schwachstelle gilt: Auf dem Knoten liegt nur so viel, wie der laufende Zahlungsverkehr braucht. Alles darüber hinaus wandert regelmäßig in eine Verwahrung, die nicht am Netz hängt. Wer diesen Abfluss automatisiert und wöchentlich statt quartalsweise durchführt, begrenzt den Schaden jedes künftigen Vorfalls auf eine überschaubare Summe.

Aufzeichnung und Steuer: Was das Finanzamt bei Bitcoin-Zahlungen verlangt

Ein Punkt, der bei Sicherheitsthemen gern untergeht, dir aber spätestens bei der nächsten Betriebsprüfung begegnet: Nimmt dein Betrieb Bitcoin als Bezahlung an, ist der Zufluss eine Betriebseinnahme. Maßgeblich ist der Wert in Euro im Zeitpunkt des Zuflusses, und dieser Wert gehört belegt. Die einjährige Haltefrist des § 23 EStG, die private Verkäufe steuerfrei stellen kann, greift für Betriebsvermögen nicht. Gewinne und Verluste aus einem späteren Verkauf bleiben im Betrieb und laufen über § 15 EStG.

Umsatzsteuerlich ist die Lage seit Längerem geklärt: Der Europäische Gerichtshof hat im Verfahren C-264/14 entschieden, dass der Umtausch konventioneller Währung in Bitcoin und zurück von der Umsatzsteuer befreit ist; das Bundesfinanzministerium hat das mit Schreiben vom 27. Februar 2018 für Deutschland umgesetzt. Deine eigentliche Lieferung oder Leistung bleibt davon unberührt steuerbar, bemessen in Euro.

Praktisch heißt das: Du brauchst je Zahlung den Zeitpunkt, den Betrag in Bitcoin, den angesetzten Eurokurs und die Herkunft dieses Kurses. BTCPay Server hält diese Angaben in seinen Rechnungsdaten vor und lässt sie exportieren. Nutze das, bevor ein Serverumzug oder ein Vorfall die Datenbank unbrauchbar macht. Dass Aufzeichnungen aufbewahrungspflichtig sind und der Zugriff während der Aufbewahrungsfrist möglich bleiben muss, ergibt sich aus § 147 der Abgabenordnung und gilt für eine SQL-Datenbank so gut wie für einen Aktenordner.

Wann sich der eigene Knoten lohnt, und wann nicht

Nach zwei Sicherheitsmeldungen in fünf Wochen ist die Frage berechtigt, ob der Aufwand noch im Verhältnis steht. Eine ehrliche Antwort muss beide Seiten nennen.

Für den eigenen Knoten spricht, dass niemand dein Geld hält, niemand dein Konto einfrieren kann und keine Gebühr pro Transaktion an einen Dienstleister abfließt. Für kleine Beträge im Lightning-Netz ist das ein spürbarer Unterschied, weil ein prozentualer Abschlag bei einem Zwei-Euro-Kauf unverhältnismäßig wäre.

Dagegen spricht der Betriebsaufwand, und der ist real. Du brauchst jemanden, der Sicherheitsmeldungen liest, Updates einspielt und Zugriffswege dokumentiert. Fehlt diese Person im Betrieb, ist ein verwahrender Zahlungsdienstleister trotz seiner Gebühren die ehrlichere Wahl. Ein schlecht gepflegter eigener Knoten ist teurer als jede Provision, und zwar genau einmal.

Ein Mittelweg, der in der Praxis gut funktioniert: eigener Knoten für das Tagesgeschäft mit begrenztem Guthaben, feste Abflüsse in die kalte Verwahrung, und ein Kalendereintrag, der dich einmal im Monat zwingt, die Veröffentlichungen des Projekts zu lesen. Die Meldungen der vergangenen Wochen hätte man so alle rechtzeitig gesehen.

BTCPay Server absichern: Was du daraus mitnimmst

1. Aktualisiere auf 2.4.4 und entferne deine eigenen LND-Weiterleitungen. Das Update allein reicht nicht, wenn du einen eigenen Weg nach außen gebaut hast. Reduziere im selben Zug das Guthaben auf dem Knoten auf den Betriebsbedarf; der Rest gehört in eine Verwahrung ohne Netzverbindung, wie sie unser Hardware-Wallet-Vergleich gegenüberstellt.
2. Setz den Fernzugriff neu auf, falls du ihn brauchst. Nutze die vorgesehene Einstellung statt einer eigenen Proxy-Regel und vergib dabei ein Macaroon mit eingeschränkten Rechten. Welche Handy-Wallet welche Verbindungsart und welche Rechtestufen beherrscht, zeigt unser Software-Wallet-Vergleich.
3. Sichere deine Zahlungsbelege, bevor du am Server schraubst. Exportiere die Rechnungsdaten mit Zeitpunkt, Betrag und angesetztem Eurokurs. Wer das laufend statt einmal jährlich erledigt, findet passende Werkzeuge in unserer Übersicht der Steuer-Tools und Portfolio-Tracker.

Die beiden Primärquellen im Wortlaut: die Ankündigung zu BTCPay Server 2.4.4 vom 8. September 2026 und der Sicherheitshinweis zu Version 2.4.2 vom 7. August 2026.

(Stand: 16. September 2026. Dieser Beitrag ist keine Anlageberatung. Kurse und Gebührenmodelle ändern sich; prüfe die Konditionen vor jedem Kauf beim Anbieter selbst.)