KI-Patches bestehen den Crash-Test – und verfehlen 1,83-mal öfter die echte Lösung
Der am 3. September 2026 veröffentlichte PatchBench-Preprint stellt die üblichen Erfolgszahlen für automatisch erzeugte Sicherheitspatches infrage. Bei 11 Agentenkonfigurationen bestanden im Mittel 83,1 Prozent der Aufgaben den ursprünglichen Proof-of-Concept-Test, aber nur 45,3 Prozent galten nach Sicherheits- und Semantikprüfungen als vollständig gelöst, wie eine unabhängige Auswertung der Benchmarkdaten darlegt.
Damit überschätzt die Prüfung mit nur einem PoC die gemessene Lösungsrate im Mittel um den Faktor 1,83. Für Security- und Entwicklungsteams lautet die entscheidende Aussage: Wenn der bekannte Eingabewert keinen Absturz mehr verursacht, ist noch nicht belegt, dass der Patch die Schwachstelle an ihrer Ursache beseitigt und das vorgesehene Programmverhalten bewahrt.
Was der Faktor 1,83 tatsächlich bedeutet
Der Wert vergleicht zwei Bewertungsverfahren: die durchschnittliche Quote bestandener Einzel-PoCs und die durchschnittliche Quote vollständig validierter Aufgaben. Er bedeutet nicht, dass jeder KI-Patch mit einer 1,83-fach höheren Wahrscheinlichkeit im Produktivbetrieb scheitert. Der zugespitzte Vergleich im Titel beschreibt vielmehr, wie stark der schwächere Test die gemessene Leistung auf diesem Benchmark aufbläht.
Ein einzelner PoC prüft nur einen bekannten Weg vom Eingabewert zum beobachteten Absturz. Ein Patch kann diesen Weg mit einer lokalen Grenzprüfung, einem frühen Rücksprung oder einer Sonderbehandlung blockieren, während derselbe Defekt über andere Eingaben erreichbar bleibt. Ebenso kann eine Änderung den Crash verhindern, indem sie zulässige Funktionen einschränkt oder Ausgaben unbemerkt verändert.
PatchBench dokumentiert dieses Muster an einer Schwachstelle im Ruby-Interpreter mruby: Die Ursache lag in der Argumentverarbeitung des Compilers, der Absturz trat jedoch später in der virtuellen Maschine auf. Ein Agent ergänzte eine Prüfung am sichtbaren Crash-Ort; der bekannte PoC lief nicht mehr in den Fehler, doch die fehlerhafte Zustandsbildung blieb bestehen und ein anderer Verarbeitungspfad konnte weiterhin einen Speicherzugriff außerhalb der Grenzen auslösen.
PatchBench prüft Sicherheit und Programmverhalten getrennt
Der PatchBench-Preprint der University of Maryland beschreibt 213 Aufgaben aus 32 realen C- und C++-Projekten und 16 CWE-Klassen. Die Forschenden wählten Schwachstellen aus, deren Referenzkorrektur außerhalb der Funktionen des Crash-Stacks liegt, und übertrugen historische Fehler mit Codeänderungen in neuere Repository-Kontexte. Dadurch soll es schwerer werden, nur am gemeldeten Absturzort einzugreifen oder eine bekannte Entwicklerkorrektur unverändert zu reproduzieren.
Die Validierung folgt drei unterschiedlichen Aussagen. Der ursprüngliche PoC zeigt, ob genau der gemeldete Crash gestoppt wurde. Weitere durch gerichtetes und ungerichtetes Fuzzing erzeugte Angriffseingaben untersuchen, ob Varianten derselben Schwachstelle weiter funktionieren. Harmlose Eingaben, Vergleiche des Programmausgabezustands und die im Referenzstand funktionierenden Unit-Tests prüfen anschließend, ob der Patch das erwartete Verhalten erhalten hat.
Eine Aufgabe zählt erst dann als gelöst, wenn die Reparatur sowohl die Sicherheits- als auch die Semantikprüfung besteht. Das erklärt die Lücke zwischen einem grünen PoC und der niedrigeren vollständigen Lösungsquote: Die zusätzlichen Tests sortieren nicht nur verbleibende Angriffswege aus, sondern auch Änderungen, die das Programm auf zulässigen Eingaben beschädigen.
Eine Prüfkette macht den Unterschied sichtbar
Ein vereinfachtes Beispiel ist ein Parser, der bei einem bestimmten überlangen Feld abstürzt. Eine Prüfung auf exakt diese Länge kann den gelieferten PoC stoppen. Erst andere Längen, abweichende Verschachtelungen und gültige Grenzfälle zeigen, ob die zugrunde liegende Speicher- oder Zustandsverletzung beseitigt wurde und zulässige Dateien weiterhin korrekt verarbeitet werden.
Für eine CI-Pipeline ergeben sich daraus unterscheidbare Prüfstufen: Der ursprüngliche PoC bleibt ein schneller Regressionstest, mehrere verwandte Angriffseingaben testen die Sicherheitswirkung, und harmlose Eingaben sowie bestehende Unit-Tests kontrollieren die funktionale Wirkung. Wo sich Ausgaben zuverlässig vergleichen lassen, kann zusätzlich ein bekannter korrekter Referenzstand zeigen, ob der Patch zwar absturzfrei ist, aber falsche Ergebnisse produziert.
Ein separates Großexperiment liefert Plausibilitätskontext, ist jedoch nicht direkt mit PatchBench vergleichbar. In der Untersuchung von 1Passwords Off-by-1 Labs lösten 26,0 Prozent von 6.080 ausgewerteten Patches eine von sechs untersuchten Schwachstellen vollständig, ohne das Anwendungsverhalten wesentlich zu verändern; 20,1 Prozent behoben den Fehler mit Verhaltensänderungen, während 53,9 Prozent die Lücke nicht schlossen, eine neue einführten oder beides.
Diese Prozentwerte lassen sich nicht mit den PatchBench-Quoten verrechnen. Off-by-1 Labs untersuchte Patchversuche zweier Modelle für sechs neuere, komplexe Schwachstellen unter einer anderen Versuchsanordnung; PatchBench verglich dagegen 11 Agentenkonfigurationen auf 213 transplantierten C- und C++-Aufgaben. Gemeinsam zeigen die Experimente lediglich, warum die Qualität eines Sicherheitspatches nicht aus einem gestoppten Einzelfehler abgeleitet werden sollte.
Die Aussage bleibt auf den Benchmark begrenzt
PatchBench ist ein noch nicht begutachteter Preprint und untersucht ausschließlich C- und C++-Schwachstellen aus einer bestimmten Aufgabenbasis. Aus dem Faktor 1,83 lässt sich deshalb keine präzise Fehlerquote für Java-, Python- oder Webanwendungen und auch keine allgemeine Erfolgswahrscheinlichkeit produktiv eingesetzter Reparaturagenten ableiten.
Auch die vollständige Testkette ist kein mathematischer Beweis für Fehlerfreiheit: Fuzzing kann weitere Pfade finden, aber nicht sämtliche möglichen Eingaben abdecken, und Semantiktests bleiben von ihren Beobachtungspunkten abhängig. Bestätigt ist derzeit der engere Befund, dass die getesteten Agentenkonfigurationen unter einer Einzel-PoC-Bewertung deutlich erfolgreicher erschienen als unter der kombinierten Sicherheits- und Semantikvalidierung. Offen bleibt, ob unabhängige Replikationen und Erweiterungen auf andere Sprachen eine ähnlich große Lücke messen.
Lesen Sie auch:
Newsletter abonnieren
Erhalten Sie die neuesten Nachrichten zu Web3, KI und Krypto direkt in Ihren Posteingang.