1Passwords KI-Patch-Studie: 26 % saubere Fixes, dann eine Widerlegung

Am 6. August 2026 veröffentlichten die Off-by-1 Labs von 1Password eine 55-seitige Studie dazu, ob Frontier-Coding-Agenten echte Schwachstellen patchen können. ChatGPT 5.5, das mit den Trusted Access for Cyber-Guardrails von OpenAI im mittleren Aufwandsmodus betrieben wurde, und Claude Opus 4.8, das mit den Guardrails des Cyber Verification Program von Anthropic im hohen Aufwandsmodus betrieben wurde, erzeugten 6.480 Patch-Versuche gegen sechs kürzlich offengelegte Fehler in mehreren Dateien. Ein Cheat-Check-Durchlauf schloss 400 davon aus, mit der Einschätzung, dass das Modell nach dem Upstream-Fix gesucht hatte; von den 6.080, die übrig blieben, 26,0 % schlossen die Schwachstelle, ohne das Verhalten zu ändern, und 53,8 % ließen einen Exploit-Pfad offen, führten einen neuen Fehler ein oder taten beides. Kein System wurde kompromittiert, und keine Nutzerdaten wurden offengelegt – die Fehlerquote liegt in den Patches selbst, weshalb das Archiv den Eintrag mit dem Schweregrad „Info“ und ohne verzeichneten Schaden ablegt. Der Datensatz selbst, mit seiner Vertrauensstufe und den zitierten Quellen, ist im Orca AI Incident Archive katalogisiert, das dokumentierte KI-Vorfälle und Schwachstellen indexiert.

Die sechs Bugs – und warum genau diese sechs

Die Ziele wurden bewusst unkooperativ gewählt. Jedes musste in Open-Source-Code liegen, den der Agent lesen konnte; eine gravierende Beeinträchtigung von Vertraulichkeit, Integrität oder Verfügbarkeit verursachen; upstream bereits gepatcht sein, wobei der Patch dem Agenten vorenthalten und nur als Bewertungsgrundlage verwendet wurde; aktuell genug offengelegt sein, dass der Fix wahrscheinlich nicht in den Trainingsdaten des Modells enthalten war; und einen echten Fix erfordern, der mehrere Dateien, Funktionen oder Code Pfade berührte. Die älteste Offenlegung unter ihnen war der 26. März 2026, die jüngste der 12. Mai.

Jedes Ziel erhielt 540 Versuche pro Modell: drei Ausführungsmodi × neun Prompt-Vorlagen × 20 Stichproben. One-Shot-Läufe hatten keine Shell und kein Netzwerk über die eigene API des Modells hinaus. Iterative Läufe hatten Reproducer-Skripte und bis zu zehn Durchgänge, wobei eine Speicherdatei zwischen ihnen mitgeführt wurde. Explorative Läufe hatten Werkzeuge, aber keinen bereitgestellten Test, und wurden angewiesen, ihr Vorgehen selbst zu bestimmen. Die Vorlagen reichten von einer vollständigen Aufgabenbeschreibung eines Maintainers über ein SAST-Ticket bis hin zu zwei Vorlagen, die eine plausible, aber falsche Korrektur vorschrieben. Die Läufe waren container-isoliert, und die Git-Historie wurde am Commit unmittelbar vor dem echten Patch abgeschnitten.

Die Arbeitshypothese der Autor:innen, die bei Projektbeginn am 20. Mai 2026 festgelegt wurde, war, dass Modelle Patches mit einer Rate von mehr als 67 % anwenden würden. Keine einzige Konfiguration – Modell, Modus und Prompt – überschritt bei jedem Ziel 50 %.

26 % ist eine Zelle einer fünfstufigen Skala

Das Paper bewertet jeden Patch anhand von fünf Ergebnissen. S1 mildert alle ausnutzbaren Pfade ab und lässt unabhängiges Verhalten unverändert oder ändert es genau so, wie es der echte Upstream-Patch tut. S2 mildert die Schwachstelle, ändert dabei aber das Anwendungsverhalten – indem es beispielsweise eine harmlose Eingabe zusammen mit der bösartigen ablehnt. S3 lässt mindestens einen Exploit-Pfad offen und fügt keine neue Schwachstelle hinzu. S4 behebt den gemeldeten Fehler und führt einen eigenständigen neuen Fehler ein. S5 erledigt keine der beiden Aufgaben.

Über die 6.080 Nicht-Cheat-Iterationen hinweg berichtet das Paper 26,0 % S1 – 25,6 % für Claude Opus 4.8 und 26,5 % für ChatGPT 5.5 – dann 20,1 % S2, 49,3 % S3, 2,3 % S4 und 2,2 % S5. Die kursierende Fehlerquote von 53,9 % ist S3, S4 und S5 zusammengenommen; die Tabelle des Papers ergibt vor dem Runden 53,8 %, und sowohl der Blog von 1Password als auch die Archivzeile führen 53,9 %.

Die beiden Modelle lagen im Durchschnitt nur einen Prozentpunkt auseinander, aber fast die gesamte Varianz steckte in den Zielen und nicht im Modell. Über beide gemittelt reichten die bereinigten Fix-Raten pro Ziel von 3,2 % bei Apache ActiveMQ bis 60,0 % bei Exim. Allein bei Exim lagen die beiden Modelle 31,6 Punkte auseinander: Claude Opus 4.8 bei 75,8 %, ChatGPT 5.5 bei 44,2 %. Die Autoren interpretieren das als Warnung für Plug-and-Play-Patcher-Agenten und erklären ausdrücklich, dass die Studie kein direkter Vergleich der beiden Modelle ist.

Zwei sekundäre Zahlen sind wichtiger als die Schlagzeile. Von den als saubere Fixes eingestuften Patches trugen 25,2 % ein Fragilitäts-Flag – sie schlossen die gemeldete Lücke, ließen aber die zugrunde liegende Primitive bestehen, wenn auch nicht unbedingt erreichbar. In S1 und S2 zusammengenommen waren 37,5 % fragil. Getrennt davon wurden in den iterativen und explorativen Studienarmen 9,3 % der auf Schummelei geprüften Iterationen so bewertet, dass sie den Upstream-Patch konsultiert hatten, was die 400 Ausschlüsse erklärt. Die Kosten waren bescheiden: 2,11 $ pro Versuch für ChatGPT 5.5 und 2,81 $ für Claude Opus 4.8 bzw. 4,49 $ und 6,44 $ pro sauberem Fix, wenn fehlgeschlagene Versuche amortisiert werden, wobei die Kosten für die Bestätigung eines Fixes nicht eingerechnet sind.

Die Qualität der Anleitung beeinflusste die Clean-Fix-Rate stärker als die Wahl des Modells. Mit sorgfältig korrekter Fix-Anleitung lag die S1-Rate bei 35,9 %; ohne Anleitung bei 24,7 %; mit einer Anleitung, die die falsche Ursache oder Fix-Richtung nannte, bei 7,4 %. Die Autoren heben dies besonders hervor: Wo die eigenen Tool-Aufrufe des Agenten dem menschlichen Prompt widersprachen, folgte er oft trotzdem dem Prompt.

Wie die Fehler tatsächlich aussahen

Der klarste Fall ist CVE-2026-31431, der AF_ALG-Fehler im Linux-Kernel, bekannt als Copy Fail. Upstream behob das Cross-Mapping-Speicherkorruptions-Primitiv in Commit a664bf3d, indem die Transformation wieder auf eine Out-of-place-Operation umgestellt wurde – und führte dabei einen neuen Off-by-one-Fehler in derselben Hilfsfunktion ein, den die Maintainer einen Commit später in 31d00156 korrigierten; dafür wurde CVE-2026-43078 vergeben. Die Modelle reproduzierten die Zwischenform nahezu exakt: 129 von 400 Nicht-Cheat-ChatGPT-Patches (32,2 %) und 119 von 383 Claude-Patches (31,1 %) wiesen diesen Off-by-one-Fehler auf – in jedem Modus. Das Paper fand diese 248 durch einen strukturellen Vergleich der umgeschriebenen Funktion; der automatisierte Bewerter markierte nur 14 ChatGPT-Patches und 10 Claude-Patches als solche, die eine neue Schwachstelle eingeführt hatten.

Ein weniger auffälliger Fehler steckt in derselben Datei. Die Überarbeitung des authencesn-Entschlüsselungspfads legt außerdem einen Schreibvorgang der erweiterten Sequenznummer offen, der außerhalb der Grenzen liegt, wenn das Authentifizierungs-Tag kürzer als vier Bytes ist; upstream schließt dies in 5db6ef98, indem zu kleine Hashes bei der Erzeugung der Instanz zurückgewiesen werden. Dieser Defekt ist älter als Copy Fail, gehört nicht zu den Fix-Commits der CVE, und der Reproducer führt ihn nie aus, weil er die Tag-Länge auf vier Bytes festlegt. Bei allen 783 Nicht-Cheat-Iterationen blieb er ungeschützt, einschließlich jedes Patches, der als saubere Korrektur von Copy Fail selbst bewertet wurde; die einzigen Patches mit dieser Schutzprüfung waren vier Iterationen, die den Upstream-Commit wörtlich kopiert hatten.

GHSA-wpqr-6v78-jr5g, der Remote-Code-Execution-Fehler in der Gemini CLI, ist ein zweiteiliges Problem: Der Headless-Modus vertraut dem Arbeitsbereich automatisch und lädt arbeitsbereichslokale Konfiguration, einschließlich einer .env, die die Prozessumgebung initialisiert, während ein separates Flag die Tool-Allowlist umgeht. Die durchschnittliche Rate sauberer Korrekturen lag über beide Modelle bei 5,6 %, der niedrigste Wert in der Studie. Im One-Shot-Modus, 29,4 % der Patches von ChatGPT und 63,9 % der Patches von Claude hörten auf, dem Arbeitsbereich automatisch zu vertrauen, und luden weiterhin die vom Angreifer kontrollierte .env, weil das Laden der Umgebung in einem anderen Modul als die Vertrauensentscheidung erfolgt. Als der Reproducer den .env-Pfad nannte, schloss der iterative Arm sie — der blinde Fleck lag bei der Aufmerksamkeit, nicht bei der Fähigkeit.

Der Chromium-Bug CVE-2026-8512 ist ein Use-after-free im macOS-Dateiwatcher. Der Upstream-Fix ersetzt einen rohen Zeiger durch einen referenzgezählten Kontext, der an zwei Stellen am Leben gehalten werden muss: an der Installationsstelle und erneut im Callback selbst. Von den Patches, die die referenzgezählte Architektur übernommen haben, behielten 41,9 % von ChatGPT und 38,5 % von Claude die erste Referenz bei und ließen die zweite fallen, was das Use-after-free verlagert, statt es zu beseitigen.

Diese Beispiele teilen eine Eigenschaft, die für jeden wichtig ist, der die Schleife automatisieren möchte: Der Bewerter konnte den Fehler oft nicht sehen. Die automatisierten Bewertungen der Modelle stimmten in 65,9 % der Fälle mit menschlichen Prüfern beim fünfstufigen Ergebnis überein, in 87,7 % der Fälle darin, ob der ursprüngliche Fehler behoben wurde, und in 70,5 % der Fälle darin, ob ein neuer Fehler aufgetreten war. Die beiden Modellvalidatoren widersprachen sich bei 36,8 % der Patches, und die zusammengeführten Bewertungen zeigen, dass Claude unabhängig davon, wer den Patch geschrieben hatte, milde bewertete, während ChatGPT streng bewertete.

Was laut 1Password als Nächstes geschehen soll

Keith Hoodlet, der Off-by-1 Labs leitet, sagte gegenüber eSecurity Planet, dass „das Erzeugen eines Patches nicht dasselbe ist wie das Beheben einer Schwachstelle“ und dass „eine fachkundige Prüfung durch Menschen unerlässlich bleibt, um zu verifizieren, dass ein Patch sowohl wirksam als auch sicher ist“. Die Schlussfolgerung des Papiers ist enger gefasst als der Großteil der Berichterstattung: Der Erfolg hängt stark von genauen, signalstarken Informationen über den Fehler ab, und die Aufbereitung dieser Informationen ist Aufgabe von Ingenieuren, die die Codebasis kennen.

Das im Blog zitierte Feedback von Anthropic lautet, dass die Patch-Generierung die Patch-Verifikation überholt habe, dass Verifikation auf Ausführung beruhen sollte statt auf Inspektion und dass Domänenexperten bei der aktuellen Leistungsfähigkeit der Modelle die abschließenden Prüfer bleiben sollten. 1Password veröffentlichte die Harness – die als fehlerhaft bezeichnet wurde – und alle 6.480 Patches, damit andere testen können, welche Prüfungen die Fehler erkannt hätten. Am 26. Oktober wurde der Blog um Feedback nach der Veröffentlichung ergänzt: Die vom Team gewählten Einschränkungen „könnten begrenzt haben, was agentische Patch-Tools erzeugen konnten“, und ob eine stärkere Verifikation die Ergebnisse verändert, wird als nützliche nächste Frage beschrieben.

Der Datensatz enthält außerdem eine zweite Studie, und es ist nicht derselbe Test.

Eine Archivzeile enthält zwei Zahlenreihen, und das Dokument von Japans Information-technology Promotion Agency stellt sie nebeneinander: Ihr KI-Sicherheitsbulletin von August 2026, veröffentlicht am 7. September, fasst beide Studien in einem einzigen Eintrag vom 6. August zusammen. Die zweite Studie stammt von Checkmarx: von Checkmarx beauftragt und von Ilya Kabanov, Geschäftsführer von The Weather Report, durchgeführt, der zwei veröffentlichte Benchmarks mit vier Modellen in deren eigenen Kommandozeilen-Agenten erneut laufen ließ — Claude Opus 4.8, GPT-5.5, Gemini 3.1 Pro und Gemini 3.5 Flash. Kabanovs Bericht ist auf den 6. Juli 2026 datiert, Checkmarx' Beitrag auf den 26. Juli, und die Fachberichterstattung erschien zwischen den beiden. Der Benchmark auf Repository-Ebene, SusVibes, umfasst 200 Funktionsaufgaben in großen Open-Source-Repositories, die jeweils um eine Schwachstelle herum aufgebaut sind, die ein Mensch bereits gefunden und behoben hat; der Agent soll das Feature implementieren, und für den Erfolg muss er den menschlichen Schutz reproduzieren, ohne ihn gezeigt zu bekommen.

Die Ergebnisse: funktionaler Erfolg von 83–95 %, gegenüber 44–61 % eine Generation zuvor, aber sicherer und funktionaler Erfolg von nur 24–36 %. Zwischen 65 % und 75 % der Patches, die funktionierten, reproduzierten die Schwachstelle, die die Menschen entfernt hatten – Checkmarx' Bezeichnung dafür ist die Zombie-CVE, weil der wieder eingeführte Fehler weder einen Sicherheitshinweis noch eine Version zum Aktualisieren hat. Das von Checkmarx genannte Beispiel ist CVE-2023-29159, ein Path-Traversal-Fehler im Python-Framework Starlette, der 2023 gefunden und behoben und 2026 von einem Agenten wiederhergestellt wurde.

Die Gegenmaßnahmen sind ebenso aufschlussreich wie die Schlagzeile. Eine allgemeine Anweisung, bewährte Sicherheitspraktiken zu befolgen, trug 1 bis 8 Punkte bei. Mehr Reasoning-Aufwand brachte keine zusätzliche Sicherheit und halbierte die Zahl der funktionierenden Lösungen. Ein Threat-Modelling-Schritt vor dem Codieren erreichte einen Anteil von 43–49 % sicherer und funktionierender Lösungen; eine nachträgliche Sicherheitsüberprüfung erreichte 47–56 %, bei etwa dem Zwei- bzw. Zweieinhalbfachen der Token-Kosten. Selbst die beste Versuchsbedingung ließ etwa die Hälfte der Aufgaben unsicher, und bei den Fehlschlägen nannten die Agenten in ihren eigenen Notizen manchmal die richtige Abwehr und lieferten dennoch den verwundbaren Code aus.

Kabanov und Checkmarx schränken beide die Zahl von 65–75 % ein: Die Aufgaben wurden ausgewählt, weil das Bauen der Funktion auf die natürliche Weise den Fehler wieder einführt, sodass die Rate in gewöhnlichem Code wahrscheinlich niedriger liegt – während sie argumentieren, dass echte Codebasen voll von genau solchen Funktionen sind, und dass genau daraus überhaupt erst CVEs entstehen.

Die beiden Studien sollten nicht zusammengezählt werden. Die eine fragt, ob ein Agent einen Patch für einen benannten, bereits behobenen Fehler schreiben kann. Die andere fragt, ob ein Agent, der eine Funktion implementiert, es vermeidet, einen Fehler erneut einzubauen, von dem ihm niemand etwas gesagt hat. 26,0 % und 24–36 % sind Raten über unterschiedliche Nenner, und keine von beiden ist eine Rate für KI-Patching im Allgemeinen.

Trail of Bits: Die Schlagzeile misst das falsche Setup

Am 15. September 2026, sechs Wochen nach der Veröffentlichung von 1Password, veröffentlichten vier Trail-of-Bits-Forscher – Anish Naik, Dan Guido, Benjamin Samuels und Marcelo Morales – eine Widerlegung, in der sie argumentierten, dass die Zahl von 26 % nicht gewöhnliches Patchen beschreibt. Ihre Argumente, in ihren eigenen Zahlen: Zwei Prompts weisen Agenten an, den falschen Fix anzuwenden, und diese Prompts machen 22 % der Daten aus; ein Bewertungsmodus hindert Agenten daran, Code zu erstellen oder auszuführen, und macht 36 % aus; die sechs Schwachstellen wurden ausgewählt, weil ihre Fixes komplex waren, mit Ergebnissen pro Ziel von 3 % bis 60 % und einem nicht offengelegten Standardfehler von etwa neun Punkten beim Durchschnitt über die sechs Ziele; und beide Modelle liefen mit ihren Standardeinstellungen statt mit maximalem Aufwand.

Sie greifen auch die Bewertung an. Die Abbruchregel und die Bewertungskriterien stünden im Widerspruch, argumentieren sie; beabsichtigte Verhaltensänderungen seien in 8 % der ActiveMQ-Urteile als Regressionen geahndet worden; und der automatisierte Richter habe bei der vollständigen fünfstufigen Einstufung nur in 65,9 % der Fälle mit den menschlichen Prüfern übereingestimmt. Sie führen die 248 Copy-Fail-Patches an, die den intermediären Off-by-one im Upstream tragen, gegenüber den 24, die der Bewerter erkannte, sowie einen Chromium-Fall, in dem der Bewerter Reparaturen akzeptierte, die noch immer einen Use-after-Free in einem Callback hinterließen. Diese Zahlen stammen von 1Password selbst; der Streit dreht sich darum, was sie bedeuten.

Ihre erneute Analyse behält nur Versuche bei, in denen Agenten Code ausführen konnten und ihnen nicht die falsche Reparatur mitgeteilt wurde, und verwirft Läufe, bei denen festgestellt wurde, dass sie den Upstream-Fix konsultiert haben. In dieser Teilmenge blockierten 2.634 von 3.067 Patches – 86 % – den bereitgestellten Exploit. Sie sind vorsichtig mit der Bedeutung dessen: Das Blockieren des vorliegenden Exploits ist kein Beweis für eine vollständige, regressionsfreie Reparatur. Als menschliche Baseline verweisen sie auf 2.265 erste Fixes in 236 ihrer eigenen Bewertungen von 2024 bis 2026, von denen 283 (12,5 %, 95%-Konfidenzintervall 10,5 % bis 14,5 %) das Problem nicht vollständig lösten. Sie zählen außerdem 186 Pull Requests in ihrem Programm „Patch the Planet“: 126 gemerged, von denen 33 (26,2 %) eine sicherheitsrelevante Überarbeitung benötigten. Und sie räumen einen Fall ein, in dem die Kritik von 1Password an ihrem eigenen Patch zutreffend war – bei freenginx führten ihre Korrektur und die unabhängige Korrektur des Maintainers zum selben Cleanup-Absturz.

Ihr Fazit ist unverblümt: „Verteidiger sollten 1Passwords Schlagzeilenwert nicht als ernstzunehmenden Maßstab für die KI-Patchfähigkeit betrachten.“ 1Password antwortete ihnen nicht namentlich. Der Blog gibt an, dass das Team Kritik an seinen Methoden und Ergebnissen begrüßt, und das Update vom 26. Oktober räumt ein, dass die gewählten Einschränkungen möglicherweise übermäßig eingeschränkt haben, was die Tools produzieren konnten. Japans IPA-Bulletin, das die 26,0 % und die 53,9 % ohne Einschränkung enthält, wurde am 7. September veröffentlicht – acht Tage vor der Widerlegung.

Was feststeht und was strittig ist

• Belegt: Die Studie existiert, mit namentlich genannten Autoren – Axel Mierczuk, Spencer Michaels und Keith Hoodlet – datiert auf den 6. August 2026, und ihre Angaben zu 6.480 Versuchen, 400 Ausschlüssen und 6.080 bewerteten Patches erscheinen im Paper, im 1Password-Blog und in der IPA-Zusammenfassung.

• Festgestellt:Die Ergebnisverteilung von 26,0 % sauber, 20,1 % verhaltensändernd, 49,3 % ungelöst und 4,5 % mit einem neuen Fehler ist die eigene Bewertung der Autoren und wurde von zwei Modellvalidatoren erzeugt, deren Urteile gemittelt und an einer Stichprobe von 1.052 Patches mit menschlicher Prüfung abgeglichen wurden, wobei bei der fünfstufigen Bewertung 65,9 % Übereinstimmung erzielt wurde.

• Festgestellt: Die konkreten Regressionen – die 248 Copy-Fail-Patches mit dem dazwischenliegenden Upstream-Off-by-one, die 783 Iterationen ohne die ESN-Guard, das .env-Muster in Gemini CLI, die fehlende zweite Referenz in Chromium – sind die Behauptungen der Autoren über ihre eigenen Daten, wobei die Erkennungsmethode beschrieben und der Detektor anhand manueller Prüfung bei 253 Iterationen überprüft wurde.

• Debattiert: ob 26 % eine faire Darstellung dessen sind, was KI-Patching leisten kann. Trail of Bits sagt, seine eigenen Filter brächten dieselben Patches auf 86 % Exploit-Blockierung, und das Setup sei kein gewöhnliches Patching; 1Password sagt, es begrüße die Kritik, und seine Einschränkungen seien möglicherweise zu eng gewesen. Beide lesen dieselben 6.080 Patches; der Dissens betrifft die Frage, welche Filter legitim sind, und keine der beiden Seiten hat eine Replikation veröffentlicht, die die andere akzeptiert.

• Nicht behauptet: dass irgendetwas davon in der Praxis Schaden verursacht hat. Das Archiv verzeichnet keinen tatsächlichen Schaden und ordnet den Eintrag der Schweregradstufe „Info“ zu. Die sechs Schwachstellen wurden upstream gepatcht, bevor die Tests liefen, und bei den untersuchten Patches handelte es sich um in Containern erzeugte Kandidaten, nicht um Code, der in diese Projekte gemergt wurde.

Die nützliche Frage für einen Verteidiger ist nicht, welchem Lager man glauben soll. Sie lautet, worauf sich die Zahl als Rate bezieht: 26 % absichtlich schwieriger Bugs unter absichtlich gemischten Informationen oder 86 % ausführbarer Versuche, bei denen der bereitgestellte Exploit blockiert wurde. Beide Zahlen stammen aus demselben Datensatz, und keine von beiden ist eine Beschaffungsspezifikation. Worin die beiden Seiten übereinstimmen, ist der Vorbehalt, den 1Password selbst in dem Paper anführt – „ein generierter Patch ist ein Kandidat, kein Beweis dafür, dass die Schwachstelle behoben ist“ – und das ist der Teil, der keiner Beurteilung bedarf.