Bitcoin Core kippt das Embargo: „Der falsche Kompromiss“ bei leicht findbaren Lücken

Bitcoin Core hat die Regeln geändert, nach denen Sicherheitslücken in der wichtigsten Bitcoin-Software öffentlich werden. Wer eine Lücke meldet, die sich mit wenig Aufwand wiederfinden lässt, löst damit ab sofort kein monatelanges Stillhalten mehr aus, sondern ein Punktrelease für jede noch gepflegte Hauptversion und eine Sicherheitsmeldung am selben Tag. Die Änderung wurde am 22. Oktober 2026 um 16:06 Uhr in die Offenlegungsrichtlinie auf bitcoincore.org übernommen.

Für dich als Halter von Bitcoin ist das keine Randnotiz aus der Entwicklerwelt. Die Richtlinie entscheidet, wie schnell ein Fehler in der Software behoben bei dir ankommt, und sie entscheidet, wie viel Vorsprung ein Angreifer in der Zwischenzeit hat. Bei rund 81.400 Dollar je Bitcoin am 23. Oktober 2026 hängt an dieser Frage der Gegenwert ganzer Wallets.

Was Bitcoin Core am 22. Oktober an der Richtlinie geändert hat

Bitcoin Core ist die Referenzsoftware des Bitcoin-Netzwerks. Sie prüft Blöcke, hält die Blockchain vor und bestimmt mit, welche Transaktionen als gültig gelten. Wer einen eigenen Node betreibt, fährt in den meisten Fällen genau diese Software.

Die Richtlinie unterscheidet nach eigener Darstellung vier Klassen von Schwachstellen. Neu hinzugekommen ist keine fünfte Klasse, sondern ein Merkmal, das quer dazu steht: Bitcoin Core kann eine gemeldete Lücke bei der Erstprüfung als easily discoverable einstufen, also als leicht auffindbar. Hängt dieses Merkmal an einer Meldung, fällt die bisherige Wartezeit weg.

Der Vorgang selbst ist nachvollziehbar dokumentiert. Der Entwickler Antoine Poinsot hat die Änderung am 16. Oktober 2026 als Pull Request 1281 eingebracht, unter dem Titel „Update security policy for easy-to-find vulnerabilities“. Nach fünfzehn Kommentaren wurde sie am 22. Oktober von einem weiteren Core-Betreuer zusammengeführt. Geändert wurde eine einzige Datei, mit zehn neuen und einer gestrichenen Zeile. Es handelt sich also nicht mehr um einen Vorschlag, sondern um die geltende Richtlinie.

„Easily discoverable“: die neue Klasse im Wortlaut der Richtlinie

Easily discoverable heißt in der Richtlinie: eine Schwachstelle, die sich mit minimalem Aufwand entdecken lässt, etwa durch einen einfachen Prompt an ein Sprachmodell. Das ist die ganze Definition, und sie ist absichtlich weit gefasst. Die Einstufung ist ausdrücklich nicht auf Funde beschränkt, die tatsächlich mit einem Sprachmodell gemacht wurden; der einfache Prompt dient als Maßstab für den Aufwand, nicht als Vorschrift für das Werkzeug.

Trägt eine Meldung dieses Merkmal, gilt laut Richtlinie: Bitcoin Core bringt für jede gepflegte Hauptversion so schnell wie möglich ein Punktrelease mit der Korrektur heraus, zusammen mit einer Sicherheitsmeldung, und wendet die sonst üblichen, von der Schwere abhängigen Embargo-Fristen nicht an. Eine Vorankündigung zwei Wochen vor der Veröffentlichung der Einzelheiten gibt es weiterhin, aber nur noch für Lücken, die tatsächlich unter Embargo stehen.

Ein Jahr Embargo gegen ein Punktrelease am selben Tag

Um zu verstehen, wie groß dieser Unterschied ist, lohnt der Blick auf die Fristen, die daneben weitergelten. Für Lücken ohne das neue Merkmal bleibt alles, wie es war.

Eine Schwachstelle mit niedriger Schwere wird zwei Wochen nach der Veröffentlichung einer Hauptversion offengelegt, die die Korrektur enthält. Bei mittlerer und hoher Schwere wird erst zwei Wochen nachdem die letzte betroffene Version das Ende ihrer Pflege erreicht hat offengelegt. Die Richtlinie beziffert diesen Punkt selbst: ungefähr ein Jahr, nachdem eine Hauptversion mit der Korrektur zuerst erschienen ist.

Daraus folgt die eigentliche Härte der alten Regel, und die Richtlinie benennt sie offen. Weil Bitcoin Core auf ein langes Embargo setzt, lassen sich Sicherheitskorrekturen in der Regel nicht in ältere Versionen zurückportieren. Sie erreichen die Nutzer erst mit der nächsten großen Version. Wer also auf einer gepflegten, aber nicht der neuesten Hauptversion sitzt, bekam eine Korrektur unter Umständen über Monate nicht.

Antoine Poinsot nennt das Embargo bei leichten Funden den falschen Kompromiss

Poinsot begründet den Schritt mit einer Abwägung, die in jeder Sicherheitsrichtlinie steckt. Transparenz und Zeit zum Aktualisieren ziehen in verschiedene Richtungen: Offenheit stellt Angreifer und Verteidiger gleich, kann eine Lücke aber öffentlich machen, bevor die Nutzer aktualisiert haben. Bitcoin Core habe sich wegen der Natur des Projekts und einer langsamen Aktualisierungskultur für das längere Embargo entschieden.

Für leicht zu findende Fehler trage diese Abwägung nicht mehr. Poinsot schreibt wörtlich, dies sei „the wrong tradeoff“, also der falsche Kompromiss, und ergänzt: „The embargo period achieves little but it delays the availability of a fixed release.“ Das Embargo erreiche also wenig, verzögere aber die Verfügbarkeit einer korrigierten Version. Als Anlass nennt er einen Anstieg bei den Meldungen zu Lücken, die sich leicht wiederentdecken lassen, und führt das darauf zurück, dass Sprachmodelle die Hürde deutlich senken, bestimmte Klassen von Fehlern zu finden oder versteckte Korrekturen zu erkennen.

Der zweite Teil dieses Satzes ist der unangenehmere. Ein stillschweigend eingebauter Fix im offenen Quellcode war früher schwer als solcher zu erkennen. Lässt sich das automatisiert aufspüren, verrät das Embargo die Lücke selbst, während es sie zu verbergen versucht.

LLMs senken die Hürde, der Red-Team-Lauf zeigt es in Zahlen

Wie stark sich die Lage verschoben hat, zeigt ein Durchlauf, über den CoinDesk am 23. Oktober 2026 berichtet. Eine Freiwilligengruppe namens Bitcoin Red Team, nach diesem Bericht sechzehn Entwickler, ließ KI-Modelle Ende Juli 2026 über 390 Bitcoin-Projekte laufen, nach Darstellung des Berichts in etwa einem Tag. Protokolliert wurden 4.962 Funde, davon 85 als kritisch eingestuft.

Diese Zahlen sind Rohbefunde und keine bestätigten Lücken, und die Berichte zu dem Durchlauf weichen voneinander ab; eine Darstellung nennt nur rund ein Fünftel der Funde als bestätigt. Als Größenordnung bleibt der Punkt trotzdem stehen: Was früher Wochen Handarbeit eines Spezialisten kostete, läuft heute über Nacht und in der Breite.

Dass daraus Schaden entsteht, ist nach demselben Bericht belegt. Eine Schwachstelle in BTCPay Server, die die Gruppe zuvor vertraulich gemeldet hatte, wurde demnach binnen Tagen auf laufenden Händler-Servern ausgenutzt und zog Lightning-Nodes leer. Core Lightning forderte seine Betreiber im August 2026 auf, Verbindungen zu trennen, nachdem sich KI-erzeugte Meldungen an das kleine Team als echt erwiesen hatten. Die Prüfung durch Menschen bleibt dabei nötig, denn ein Teil der maschinell erzeugten Meldungen beschreibt am Ende gar keine Schwachstelle.

Dass eine Lücke nicht von einem Sprachmodell gefunden werden muss, um teuer zu werden, zeigt ein Fall aus demselben Sommer. In der Firmware der Hardware-Wallet Coldcard schlummerte nach dem Bericht seit 2021 ein Fehler, über den am 30. Juli 594 Bitcoin in 25 Minuten abgezogen wurden; über vier Abzüge summierte sich der Verlust auf knapp 114 Millionen Dollar. Wer die Modelle verschiedener Anbieter und ihre Aktualisierungswege vergleichen will, findet die Übersicht im Vergleich der Hardware-Wallets.

Drei Hauptversionen gelten als gepflegt: 29.x, 30.x und 31.x

„Jede gepflegte Hauptversion“ ist der entscheidende Halbsatz der neuen Regel, denn er sagt dir, ob ein Punktrelease dich überhaupt erreicht. Bitcoin Core hält sich dabei an eine knappe Zusage: Gepflegt werden stets die letzten drei Hauptversionen, so steht es im Lebenszyklus-Plan des Projekts auf bitcoincore.org.

Derzeit sind das drei Stände. Version 31.x erschien am 19. April 2026 und ist die aktuelle Ausgabe. Version 30.x stammt vom 10. Oktober 2025, Version 29.x vom 14. April 2025. Das Ende der Pflege ist jeweils an die kommenden Hauptversionen gekoppelt und nicht an ein festes Datum. Version 28.x ist am 19. April 2026 aus der Pflege gefallen und bekommt damit auch kein Punktrelease aus der neuen Regel.

So prüfst du, welche Core-Version dein eigener Node fährt

Wenn du einen eigenen Node betreibst, ist die Versionsnummer die einzige Angabe, die über deine Lage entscheidet. Sie steht in der Oberfläche von Bitcoin Core unter dem Menüpunkt zur Programminformation, und auf der Kommandozeile liefert sie der Aufruf bitcoin-cli -version. Liegt die erste Zahl unter 29, bist du außerhalb der Pflege, und keine der hier beschriebenen Korrekturen wird dich erreichen.

Zwei weitere Punkte sind jetzt wichtiger als vorher. Erstens lohnt es sich, die Sicherheitsmeldungen des Projekts zu verfolgen, weil Meldung und korrigierte Version künftig am selben Tag erscheinen und der zeitliche Vorlauf fehlt. Zweitens ist die Reaktionszeit zu deinem Nachteil kürzer geworden: Mit der Veröffentlichung sind die Einzelheiten öffentlich, und wer nicht aktualisiert, läuft mit einer bekannten Lücke weiter. Dasselbe Prinzip gilt für die Software-Wallet auf deinem Rechner oder Handy, deren Aktualisierungswege im Vergleich der Software-Wallets nebeneinander stehen.

Für Halter ohne eigenen Node verschiebt sich die Verantwortung

Die große Mehrheit der Anleger in Deutschland betreibt keinen eigenen Node. Für sie wirkt die Änderung mittelbar, und zwar über die Dienste, die Bitcoin Core im Hintergrund fahren. Dazu gehören Börsen, Verwahrer, Zahlungsdienstleister und die Server, die hinter manchen Wallet-Apps stehen.

Dort ist die neue Regel zuerst eine gute Nachricht. Ein Betreiber, der bisher auf eine große Version warten musste, bekommt die Korrektur nun als Punktrelease für den Stand, den er ohnehin fährt. Das senkt die Hürde, überhaupt zu aktualisieren. Gleichzeitig steigt der Druck, es schnell zu tun, weil die Einzelheiten der Lücke zur gleichen Zeit öffentlich werden.

Hardware-Wallets und Börsen hängen an derselben Offenlegung

Eine Einschränkung gehört dazu, damit die Reichweite dieser Änderung nicht überschätzt wird. Sie betrifft Bitcoin Core, nicht den gesamten Bitcoin-Werkzeugkasten. Hardware-Wallets, Wallet-Apps, Zahlungsserver und Lightning-Umsetzungen haben jeweils eigene Richtlinien, und die Fälle aus diesem Sommer stammen zum größeren Teil aus genau diesen Projekten. Die Frage, wie zügig ein Anbieter Firmware und App nachzieht, bleibt eine Frage an den Anbieter.

Für dich heißt das: Die Entscheidung, ob du selbst verwahrst oder verwahren lässt, verschiebt lediglich, wer das Aktualisieren übernimmt. Sie nimmt die Aufgabe nicht weg. Wer selbst verwahrt, trägt die Versionspflege für Node und Wallet. Wer bei einem Verwahrer liegt, verlässt sich darauf, dass dessen Technik die Punktreleases zeitnah einspielt, und tauscht Kontrolle gegen Zuständigkeit.

Ein weiterer Punkt steht noch offen. Bis zum 23. Oktober 2026 war nach dem Bericht von CoinDesk keine Lücke unter der neuen Regel eingestuft worden. Wie kurz „so schnell wie möglich“ in der Praxis ausfällt, wird sich erst am ersten echten Fall zeigen. Auch Poinsot räumt ein, dass solche Korrekturen weniger Zeit zum Reifen haben, bevor sie die Nutzer erreichen. Einen Vorschlag, auf die Sicherheitsmeldung ganz zu verzichten, hat er dagegen abgelehnt: Nutzer über eine Lücke zu informieren, ohne Einzelheiten zu nennen, könne unnötig zusätzliches Risiko schaffen.

Bitcoin Core: Punktrelease und Advisory kommen am selben Tag

1. Versionsnummer feststellen. Prüfe bei einem eigenen Node, ob die erste Zahl 29, 30 oder 31 lautet. Liegt sie darunter, aktualisiere auf einen gepflegten Stand. Für die Wallet-Seite hilft der Vergleich der Software-Wallets bei der Frage, wie der Anbieter seine Aktualisierungen ausliefert.
2. Firmware der Hardware-Wallet nachziehen. Die Coldcard-Lücke lag nach dem Bericht vier Jahre in der Firmware. Prüfe, wann du zuletzt aktualisiert hast, und wie dein Modell Aktualisierungen überhaupt bekommt; der Vergleich der Hardware-Wallets stellt die Anbieter nebeneinander.
3. Zuständigkeit klären. Entscheide, wer bei dir das Aktualisieren übernimmt. Liegt ein Teil deiner Bestände bei einem Verwahrer, prüfe dessen Angaben zur Technik; eine Einordnung der Anbieter steht im Börsenvergleich.

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