Patch-Diffs sind jetzt Angriffskarten – das offene Modell GLM 5.3 zeigt es

Was, wenn das gefährlichste Dokument im Open-Source-Bereich gar kein Schwachstellenbericht ist, sondern der Fix dafür? Das ist der unbequeme Gedanke hinter einem neuen Experiment: Ein öffentlicher Patch in einem Repository lässt sich womöglich von einem Modell lesen und zur Waffe machen, das laut Epoch AI etwa 1.000 $ pro Exploit kostet.

Ein Modell für 1.000 $ machte öffentliche Fixes zu Exploits

Laut dem Bericht von Epoch AI kann GLM 5.3, ein im August von Z.ai veröffentlichtes Open-Weight-Modell, Schwachstellen in aktuellen Firefox-Versionen erkennen und ausnutzen – anhand von Sicherheitsfixes, die zwar veröffentlicht, aber noch nicht an die Nutzer ausgeliefert wurden. Dieses Zeitfenster heißt Patch-Lücke (Patch Gap). Die Forscher geben an, den Versuchsaufbau so gestaltet zu haben, dass er einen wenig versierten Hacker mit begrenzten Mitteln nachahmt, und zwar nur mit Informationen, die zum Zeitpunkt der jeweiligen Veröffentlichung verfügbar waren.

Die berichteten Ergebnisse: Exploit-Ketten gegen sechs aktuelle Firefox-Releases, jeweils für rund 1.000 $ und ohne dass das Modell sich verweigerte, so sekundäre Berichte wie explainx.ai. Mozilla hat inzwischen eine verwandte Schwachstelle behoben. Zu beachten ist, dass wir uns auf Epochs eigene Darstellung und Pressezusammenfassungen stützen; eine unabhängige Replikation haben wir nicht gesehen.

Der Patch ist der Schwachstellenbericht

Open Source beruht seit Langem auf einem Tauschgeschäft: Fixes werden öffentlich gemacht, weil Transparenz Vertrauen schafft und viele Augen die Änderung prüfen können. Dabei galt als Voraussetzung, dass es Können, Zeit und Geduld brauchte, einen Patch per Reverse Engineering in einen zuverlässigen Exploit zu verwandeln. Geübte Menschen konnten das, aber wohl nicht in großem Maßstab.

Wenn ein Modell das für 1.000 $ pro Stück erledigt, kippt die Rechnung. Eine Commit-Nachricht wie „fix out-of-bounds write“ ist keine Notiz an Kollegen mehr, sondern ein Hinweis darauf, wo der Fehler steckt. Unserer Einschätzung nach war nie die Schwachstelle die knappe Ressource, sondern die Aufmerksamkeit des Angreifers – und genau die machen Sprachmodelle billig.

Das bestraft zugleich die Gewissenhaften. Projekte, die Fixes schnell und offen einchecken, schaffen die Lücke zwischen sichtbarem und ausgeliefertem Fix. Je schneller man öffentlich arbeitet, desto länger bleibt das Ziel ausgeleuchtet – es sei denn, die Auslieferung hält Schritt.

Offene Gewichte verantwortlich zu machen, verfehlt das eigentliche Problem

Es ist verlockend, daraus eine Geschichte über Open-Weight-Modelle zu machen. Wir halten das für das falsche Ziel. Dass das Modell Berichten zufolge nie ablehnte, ist beachtenswert, doch ein geschlossenes Modell mit starken Schutzmechanismen würde wohl nur ändern, wer die Fähigkeit zuerst bekommt und wie leicht sich die Sperren umgehen lassen. Das zugrunde liegende Problem ist die Struktur der Offenlegung, nicht die Lizenz des Modells.

Ein Verbot oder eine Beschränkung von Gewichten würde die Patch-Lücke nicht schließen. Was dann? Kürzere Lücken. Release-Prozesse, bei denen der öffentliche Commit und das Update für die Nutzer gleichzeitig erscheinen. Fixes unter Embargo, die in privaten Branches bleiben, bis die Builds bereit sind. Weniger aussagekräftige Commit-Nachrichten – hier sind wir allerdings skeptisch: Ein Modell, das Code-Diffs liest, braucht die Commit-Nachricht nicht, um die Änderung zu finden.

Nicht jedes Projekt kann das umsetzen. Große Anbieter mit automatischen Updates und eng getakteten Releases können die Lücke verkleinern. Eine von Freiwilligen betreute Bibliothek kann das nicht. In dieser Asymmetrie erwarten wir den eigentlichen Schaden: im langen Schwanz jener Software, die öffentlich patcht und langsam aktualisiert.

Maintainer sollten zuerst ausliefern und später erklären

Für Maintainer lautet die Empfehlung unmissverständlich: Der Moment, in dem ein Fix sichtbar wird, sollte als der Moment gelten, ab dem ein Exploit existieren kann. Die eigene Lücke in Stunden messen, nicht in Wochen, und erwägen, Sicherheits-Commits zurückzuhalten, bis das Release auslieferungsbereit ist. Transparenz kann unmittelbar nach der Auslieferung folgen statt davor.

Für alle anderen ist der Rat langweilig und dringlicher denn je: automatische Updates aktivieren und den Browser neu starten, wenn er dazu auffordert. Die Kosten der Verzögerung lassen sich nun in Dollar beziffern.

Eine Einschränkung: Es handelt sich um ein einzelnes Experiment, das sich auf Firefox konzentriert, und einer Zusammenfassung zufolge hielt Chrome stand. Wir sollten es daher nicht auf alle Software hochrechnen. Die Richtung scheint aber deutlich genug. Patch-Diffs waren früher Dokumentation. Heute wirken sie wie eine Karte, und die einzig sinnvolle Antwort lautet, die Karte nicht mehr auszulegen, bevor die Straße gebaut ist.