Die Northwestern University hat 112 historische Sicherheitsfehler aus 84 Open-Source-Projekten für die Evaluation von AI-Coding-Agenten aufbereitet. Beim getesteten Claude Opus 4.7 verhinderten 90,2 Prozent der erzeugten Patches, dass der ursprüngliche Proof of Concept den Fehler erneut auslöste. Nur 60,7 Prozent bestanden zusätzlich Tests aus den ursprünglichen Maintainer-Fixes.
Unter den Patches mit bestandenem PoC-Test scheiterten 32,7 Prozent an diesen Maintainer-Tests. Das ist keine allgemeine Fehlerquote von Claude beim Programmieren. Die Messung gilt für diesen Datensatz, den OpenCode-Harness und die festgelegte Testumgebung. Das Paper erschien am 7. Oktober; Help Net Security hat es am 12. Oktober aufgearbeitet.
Ein behobener Absturz ist noch keine korrekte Reparatur
Die 112 Fälle stammen aus C/C++, Go und Rust. Für jeden Fall bauten die Forscher eine reproduzierbare Umgebung mit dem fehlerhaften Stand, einem auslösenden Test, bestehenden Regressionstests und Tests aus dem späteren Maintainer-Fix.
Ein Beispiel aus PHP verdeutlicht das Problem: Ein Patch kann den Absturz durch eine pauschale Ablehnung bestimmter Eingaben verhindern. Die Software akzeptiert dann aber auch zuvor gültige Eingaben nicht mehr. Ein Test, der nur den ursprünglichen Absturz prüft, bewertet den Patch als erfolgreich. Der Maintainer-Test erkennt die unerwünschte Verhaltensänderung.
Die Forscher untersuchten drei Claude-Generationen mit demselben Harness. Bei Sonnet 4.0 bestanden 77,7 Prozent den PoC-Test und 43,8 Prozent den Maintainer-Test. Bei Sonnet 4.5 waren es 84,8 beziehungsweise 48,2 Prozent. Opus 4.7 erreichte 90,2 und 60,7 Prozent. Die Lücke wird kleiner, bleibt aber groß.
Der Benchmark konnte dem Agenten die Lösung verraten
Die Studie dokumentiert Fehlerquellen außerhalb des Modells. Ein Agent rief über die Websuche direkt einen öffentlichen Commit mit der ursprünglichen Reparatur ab. In einem anderen Lauf fand ein Agent einen verwandten Fix in der mitgelieferten Git-Historie. Beides sind für Entwickler normale Recherchewege. Einen Benchmark, der eigenständige Fehleranalyse messen soll, können sie verfälschen.
Auch der Harness beeinflusste die Werte. Allein die Bereitstellung genauer Build- und Testanweisungen erhöhte die PoC-Erfolgsrate in den C/C++-Fällen von 72 auf 92 Prozent. Das Modell blieb unverändert. Umgekehrt führten versteckte Hintergrundprüfungen und Konflikte mit vom Agenten geschriebenen Tests zu Fehlschlägen, die nicht auf einen falschen Patch zurückgingen.
Patching-Evaluationen müssen erwartetes Verhalten prüfen
Für automatische Security-Fixes reicht die Aussage „PoC läuft nicht mehr“ nicht aus. Eine Prüfung muss auch benachbarte, weiterhin gültige Eingaben und die vom Projekt erwartete Funktion abdecken. Sonst kann eine Einschränkung des Programms als Reparatur erscheinen.
Bei historischen Bugs gehört die Herkunft der Informationen zur Testbeschreibung: War das Repository auf den fehlerhaften Commit begrenzt? Hatte der Agent Internetzugang? Waren spätere Fixes oder Bewertungsskripte lesbar? Ohne diese Angaben lassen sich Erfolgsquoten nicht sinnvoll vergleichen.
Die Autoren untersuchten 13 vorhandene Patching-Benchmarks und Datensätze. Jeder der fünf speziell für AI-Agenten ausgelegten Benchmarks ließ mindestens eine der neun beschriebenen Fehlerquellen offen. Die Studie ist keine Rangliste produktiver Patchsysteme; sie misst, wie stark deren Bewertung von Testdesign und Harness abhängen kann.
Quellen: Le, Shi und Xing, „On the Reliability of LLM-Based Vulnerability Patching Benchmarks“, arXiv:2610.10150, 7. Oktober 2026, https://arxiv.org/abs/2610.10150; Help Net Security, „AI vulnerability patching has a grading problem“, 12. Oktober 2026, https://www.helpnetsecurity.com/2026/10/12/ai-vulnerability-patching-grading-problem/.