Bitcoin Core, die Referenzimplementierung des Bitcoin-Protokolls, hat eine Überarbeitung seiner Richtlinie zur Offenlegung von Schwachstellen beschlossen: Bugs, die sich mit minimalem Aufwand finden lassen, werden nun sofort gepatcht und offengelegt – ohne die Embargo-Frist, die üblicherweise zwischen Fix und öffentlicher Bekanntgabe liegt.

Was sich bei den Offenlegungsregeln geändert hat

Der Entwickler Antoine Poinsot kündigte die Revision am 22. Oktober 2026 in einer Diskussion auf der Bitcoin Development Mailing List an. Das Update führt eine neue Schwachstellenkategorie mit der Bezeichnung „easily discoverable“ ein, die Schwachstellen umfasst, die sich mit geringem Aufwand identifizieren lassen. Das prominenteste Beispiel sind alles, was aus einfachen Prompts an große Sprachmodelle (LLMs) hervorgeht – die Technologie hinter modernen KI-Chatbots.

Bugs in dieser Kategorie erhalten eine andere Behandlung als alle übrigen: Fixes werden sofort auf jede aktiv unterstützte Hauptversion von Bitcoin Core zurückportiert, und ein Sicherheitshinweis wird gleichzeitig veröffentlicht.

Der Rest der Richtlinie bleibt unverändert. Schwachstellen mit geringem Schweregrad werden weiterhin zwei Wochen nach einem Major-Release offengelegt. Schwachstellen mittleren und hohen Schweregrades warten weiterhin, bis zwei Wochen nach dem End-of-Life der letzten betroffenen Version vergangen sind – ein Zeitraum, der typischerweise etwa ein Jahr nach dem Fix liegt. Kritische Schwachstellen bleiben vollständig außerhalb des neuen Rahmens und werden weiterhin ad hoc behandelt.

Diese Wartefristen sind ein fester Bestandteil der koordinierten Offenlegung von Schwachstellen in der Softwarebranche: Der Fix erscheint zuerst, und die öffentlichen Details folgen, sobald die Nutzer Zeit zum Aktualisieren hatten – so wird begrenzt, wie weit eine Schwachstelle bekannt wird, bevor Patches verfügbar sind.

Warum KI die Änderung nötig machte

Die Änderung reagiert auf eine Zunahme von Schwachstellenberichten im Zusammenhang mit der wachsenden Nutzung von KI-Tools, die bestimmte Arten von Problemen leichter aufspürbar und leichter reproduzierbar gemacht haben.

Das Bitcoin-Core-Team räumte die damit verbundenen Abwägungen ein. Auf der einen Seite steht Transparenz; auf der anderen die Dringlichkeit, Nutzer zu Updates zu bewegen. Bei Schwachstellen, die sich leicht wiederfinden lassen, kam das Team zu dem Schluss, dass langwierige Embargos keinen nennenswerten Nutzen bringen.

Die Begründung ergibt sich aus der Technologie selbst: Ein Embargo bietet nur Schutz, solange eine Schwachstelle schwer zu finden ist – und ein Bug, den ein Chatbot mit einem einfachen Prompt zutage fördert, lässt sich jederzeit wiederfinden.

Z Details fallen besonders auf. Erstens wurde noch keine Schwachstelle in die neue Kategorie eingeordnet, sodass die Richtlinie bislang nicht auf einen echten Bug angewendet wurde. Zweitens ist die Kategorie nicht auf KI-entdeckte Probleme beschränkt: Entscheidend ist, wie leicht eine Schwachstelle zu finden ist – nicht, welches Werkzeug sie gefunden hat.

Was das für Node-Betreiber bedeutet

Die unmittelbarste Auswirkung betrifft Betreiber von Bitcoin-Core-Nodes. Wird ein leicht auffindbarer Bug entdeckt, können Patch und Sicherheitshinweis zusammen eintreffen – ohne Schonfrist, bevor die Details öffentlich werden. Damit entfällt der Abstand zwischen der Verfügbarkeit eines Fixes und dem Zeitpunkt, an dem die dahinterstehende Schwachstelle allgemein bekannt ist.

Das Zurückportierungsversprechen ist hier relevant. Da Fixes für alle aktiv unterstützten Hauptversionen bereitgestellt werden, erhalten auch Betreiber, die nicht die neueste Version einsetzen, einen Patch, ohne auf eine neue Hauptversion wechseln zu müssen.

Die offenen Fragen sind praktischer Natur: Wie wird das Team entscheiden, was als „easily discoverable“ gilt, und wie konsistent wird diese Grenze gezogen, sobald erste echte Berichte eingehen? Der erste Bug, der in die Kategorie eingeordnet wird, wird die klarste Antwort liefern.