Illustrazione astratta di due flussi di tessere di differenze di codice che convergono su un'unica porta, con la maggior parte delle tessere fratturate e una piccola minoranza che passa intatta; il logo OrcaRouter si trova nell'angolo inferiore destro.
AI Safety Incidents

Lo studio di 1Password sulle patch AI: 26% di correzioni pulite, poi una replica

Autore

Magnus Corvin

Data di pubblicazione

Ultimi modelli · 20Vedi tutti i modelli →
Benchmark: Artificial Analysis · aggiornato ogni giorno
Torna a tutti gli articoli

Il 6 agosto 2026, Off-by-1 Labs di 1Password ha pubblicato uno studio di 55 pagine che esamina se gli agenti di programmazione frontier possono correggere vulnerabilità reali. ChatGPT 5.5, eseguito con i guardrail Trusted Access for Cyber di OpenAI a sforzo medio, e Claude Opus 4.8, eseguito con i guardrail del Cyber Verification Program di Anthropic a sforzo alto, hanno prodotto 6.480 tentativi di patch contro sei bug multi-file divulgati di recente. Un controllo anti-imbrogli ha escluso 400 di essi, ritenendo che il modello avesse cercato la correzione upstream; dei 6.080 rimasti, 26,0% ha risolto la vulnerabilità senza modificare il comportamento, e il 53,8% ha lasciato aperto un percorso di exploit, introdotto una nuova falla, o entrambe le cose. Nessun sistema è stato compromesso e nessun dato utente è stato esposto — il tasso di difetti è nelle patch stesse, motivo per cui l'archivio registra la voce con gravità info e nessun danno documentato. Il record stesso, con il suo grado di confidenza e le fonti citate, è catalogato nell'Orca AI Incident Archive, che indicizza incidenti e vulnerabilità documentati relativi all'IA.

I sei bug, e perché proprio questi sei

Gli obiettivi sono stati scelti per essere ostili. Ognuno doveva risiedere in codice open source che l'agente potesse leggere; causare una grave compromissione della riservatezza, dell'integrità o della disponibilità; essere già stato correttato upstream, con quella patch non fornita all'agente e usata solo come baseline di valutazione; essere stato divulgato abbastanza di recente da rendere improbabile che la correzione fosse presente nei dati di addestramento del modello; e richiedere una correzione reale che toccasse più file, funzioni o percorsi di codice. La divulgazione più vecchia tra queste era il 26 marzo 2026 e la più recente il 12 maggio.

Table of the six vulnerabilities tested by Off-by-1 Labs, listing the identifier, affected software, flaw type, CVSS score and disclosure date: CVE-2026-22738 in Spring AI, unauthenticated remote code execution, 9.8, disclosed 26 March 2026; CVE-2026-31431 in the Linux kernel, local privilege escalation, 7.8, 29 April; CVE-2026-34197 in Apache ActiveMQ, authenticated remote code execution, 8.8, 7 April; GHSA-wpqr-6v78-jr5g in Gemini CLI, code execution with trust bypass via prompt injection, 10.0, 23 April; CVE-2026-45185 in Exim, unauthenticated remote code execution, 9.8, 12 May; CVE-2026-8512 in Google Chrome, sandbox escape requiring user interaction, 8.3, 12 May.

Ogni target ha ricevuto 540 tentativi per modello: tre modalità di esecuzione × nove template di prompt × 20 campioni. Le esecuzioni one-shot non avevano shell né rete oltre all'API del modello stesso. Le esecuzioni iterative avevano script di riproduzione e fino a dieci passaggi, con un file di memoria mantenuto tra di essi. Le esecuzioni esplorative avevano strumenti ma nessun test fornito, e veniva detto loro di decidere autonomamente il proprio corso d'azione. I template spaziavano dal brief completo di un maintainer, passando per un ticket SAST, fino a due che prescrivevano una correzione plausibile ma errata. Le esecuzioni erano isolate in container, e la cronologia git era tagliata al commit immediatamente precedente alla patch reale.

L'ipotesi di lavoro degli autori, fissata all'inizio del progetto il 20 maggio 2026, era che i modelli avrebbero applicato patch a un tasso superiore al 67%. Nessuna singola configurazione — modello, modalità e prompt — ha superato il 50% su ogni target.

26% è una cella di una scala in cinque parti

L'articolo valuta ogni patch in base a cinque esiti. S1 mitiga tutti i percorsi sfruttabili e lascia invariato il comportamento non correlato, oppure lo modifica esattamente come fa la patch upstream reale. S2 mitiga la vulnerabilità ma nel farlo modifica il comportamento dell'applicazione — ad esempio rifiutando un input benigno insieme a quello malevolo. S3 lascia aperto almeno un percorso di exploit e non aggiunge alcun nuovo difetto. S4 corregga il bug segnalato e ne introduce un altro distinto. S5 non svolge nessuno dei due compiti.

Bar chart of the 6,080 graded patches by outcome: S1 complete and behaviour-preserving 26.0 percent, S2 fixed but behaviour changed 20.1 percent, S3 vulnerability left open 49.3 percent, S4 fixed with a new vulnerability 2.3 percent, S5 neither fixed nor safe 2.2 percent, with a footer noting 400 attempts excluded as upstream-fix lookups and a 9.3 percent cheat rate among cheat-checked iterations.

Su 6.080 iterazioni non-cheat, il paper riporta 26,0% per S1 — 25,6% per Claude Opus 4.8 e 26,5% per ChatGPT 5.5 — poi 20,1% per S2, 49,3% per S3, 2,3% per S4 e 2,2% per S5. La cifra di fallimento che circola, 53,9%, è la combinazione di S3, S4 e S5; la tabella del paper somma a 53,8% prima dell'arrotondamento, e sia il blog di 1Password sia la riga dell'archivio riportano 53,9%.

I due modelli sono arrivati in media a un punto percentuale di distanza l'uno dall'altro, ma quasi tutta la variazione era nei target piuttosto che nel modello. Facendo la media tra i due, i tassi di correzione pulita per target variavano dal 3,2% su Apache ActiveMQ al 60,0% su Exim. Solo su Exim i due modelli erano separati da 31,6 punti: Claude Opus 4.8 al 75,8%, ChatGPT 5.5 al 44,2%. Gli autori interpretano questo come un avvertimento per gli agenti patcher plug-and-play e affermano esplicitamente che lo studio non è un confronto testa a testa tra i due modelli.

Due numeri secondari contano più del titolo. Tra le patch classificate come correzioni pulite, il 25,2% presentava un flag di fragilità: chiudevano il buco segnalato ma lasciavano in piedi la primitiva sottostante, anche se non necessariamente raggiungibile. Considerando S1 e S2 insieme, il 37,5% era fragile. Separatamente, nei rami iterativi ed esplorativi, il 9,3% delle iterazioni sottoposte a controllo anti-imbroglio è stato giudicato come avere consultato la patch upstream, ed è da lì che sono venute le 400 esclusioni. Il costo è stato modesto: 2,11 $ per tentativo per ChatGPT 5.5 e 2,81 $ per Claude Opus 4.8, oppure 4,49 $ e 6,44 $ per correzione pulita una volta ammortizzati i tentativi falliti, escluso il costo per confermare una correzione.

La qualità delle indicazioni ha spostato il tasso di correzioni pulite più di quanto abbia fatto la scelta del modello. Con indicazioni di correzione attentamente corrette, il tasso S1 era del 35,9%; senza indicazioni, 24,7%; con indicazioni che indicavano la causa radice o la direzione di correzione sbagliate, 7,4%. Gli autori evidenziano in particolare questo aspetto: quando le chiamate agli strumenti effettuate dall'agente stesso contraddicevano il prompt umano, l'agente spesso seguiva comunque il prompt.

Che aspetto avevano realmente i guasti

Il caso più chiaro è CVE-2026-31431, il bug AF_ALG del kernel Linux noto come Copy Fail. Upstream ha corretto la primitiva di corruzione della memoria tramite mappatura incrociata nel commit a664bf3d riportando la trasformazione a un'operazione out-of-place — e ha introdotto un nuovo off-by-one nello stesso helper, che i manutentori hanno corretto un commit dopo in 31d00156, a cui è stata assegnata CVE-2026-43078. I modelli hanno riprodotto la forma intermedia quasi esattamente: 129 delle 400 patch ChatGPT non-cheat (32,2%) e 119 delle 383 patch Claude (31,1%) presentavano quell'off-by-one, in ogni modalità. L'articolo ha individuato quelle 248 tramite confronto strutturale della funzione riscritta; il grader automatizzato ha segnalato solo 14 patch ChatGPT e 10 patch Claude come aventi introdotto una nuova vulnerabilità.

Una svista più silenziosa si trova nello stesso file. Rielaborare il percorso di decrittazione di authencesn espone anche una scrittura dell'extended sequence number che va fuori dai limiti quando il tag di autenticazione è più corto di quattro byte; upstream la chiude in 5db6ef98 rifiutando gli hash di dimensioni insufficienti al momento della creazione dell'istanza. Questo difetto precede Copy Fail, non è tra i commit di correzione della CVE, e il riproduttore non lo esercita mai perché fissa la lunghezza del tag a quattro byte. Tutte le 783 iterazioni non-cheat lo hanno lasciato senza protezione, incluse tutte le patch valutate come correzione pulita di Copy Fail stesso; le uniche patch che includevano la protezione erano quattro iterazioni che avevano copiato alla lettera il commit upstream.

GHSA-wpqr-6v78-jr5g, il bug di esecuzione di codice remoto di Gemini CLI, è un problema in due parti: la modalità headless considera automaticamente attendibile il workspace e carica la configurazione locale del workspace, incluso un .env che inizializza l'ambiente del processo, mentre un flag separato aggira la allowlist degli strumenti. Il tasso medio di correzioni pulite per entrambi i modelli era del 5,6%, il più basso dello studio. In modalità one-shot, il 29,4% delle patch di ChatGPT e il 63,9% di quelle di Claude ha smesso di considerare automaticamente attendibile il workspace e ha comunque caricato il .env controllato dall'attaccante, perché il caricamento dell'ambiente avviene in un modulo diverso da quello della decisione di attendibilità. Quando il reproducer ha indicato il percorso del .env, il ramo iterativo l'ha chiuso — il punto cieco era l'attenzione, non la capacità.

Il bug di Chromium, CVE-2026-8512, è un use-after-free nel file watcher di macOS. La correzione upstream sostituisce un puntatore raw con un contesto a conteggio di riferimenti che deve essere mantenuto vivo in due punti: nel sito di installazione e, ancora, all'interno della callback stessa. Tra le patch che hanno adottato l'architettura a conteggio di riferimenti, il 41,9% di quelle di ChatGPT e il 38,5% di quelle di Claude ha mantenuto il primo riferimento e lasciato cadere il secondo, il che sposta lo use-after-free anziché eliminarlo.

Questi esempi condividono una proprietà che conta per chiunque pianifichi di automatizzare il ciclo: il valutatore spesso non riusciva a vedere il fallimento. I punteggi automatici dei modelli coincidevano con quelli dei revisori umani sull'esito a cinque vie nel 65,9% dei casi, sul fatto che il bug originale fosse stato corretto nell'87,7% dei casi e sul fatto che fosse comparso un nuovo bug nel 70,5% dei casi. I due validatori dei modelli non erano d'accordo tra loro sul 36,8% delle patch, e i punteggi aggregati mostrano che Claude valutava con indulgenza chiunque avesse scritto la patch, mentre ChatGPT valutava in modo severo.

Cosa dice 1Password che dovrebbe succedere dopo

Keith Hoodlet, che guida Off-by-1 Labs, ha detto a eSecurity Planet che "generare una patch non equivale a correggere una vulnerabilità" e che "la revisione umana esperta resta essenziale per verificare che una patch sia efficace e sicura". La conclusione del documento è più circoscritta di gran parte della copertura: il successo dipende fortemente da informazioni accurate e ad alto segnale sul bug, e curarle è un compito per ingegneri che conoscono la base di codice.

Il feedback di Anthropic, citato nel blog, è che la generazione di patch ha superato la verifica delle patch, che la verifica dovrebbe essere basata sull'esecuzione anziché sull'ispezione, e che gli esperti di dominio dovrebbero rimanere i revisori finali con l'attuale capacità dei modelli. 1Password ha rilasciato l'harness, chiamato flawed, e tutte le 6.480 patch, così che altri possano verificare quali controlli avrebbero individuato i fallimenti. Il 26 ottobre il blog è stato aggiornato con feedback successivi alla pubblicazione: i vincoli scelti dal team «potrebbero aver limitato ciò che gli strumenti di patching agentico potevano produrre», e se una verifica più rigorosa cambi gli esiti viene descritto come un'utile prossima domanda.

Il documento riporta anche un secondo studio, e non è lo stesso test.

Una riga dell'archivio contiene due serie di numeri, e l'Information-technology Promotion Agency del Giappone è il documento che le mette a confronto: il suo bollettino sulla sicurezza AI di agosto 2026, pubblicato il 7 settembre, riassume entrambi gli studi in un'unica voce datata 6 agosto. Il secondo studio è di Checkmarx: commissionato da Checkmarx e condotto da Ilya Kabanov, amministratore delegato di The Weather Report, che ha rieseguito due benchmark pubblicati su quattro modelli nei loro rispettivi agenti da riga di comando — Claude Opus 4.8, GPT-5.5, Gemini 3.1 Pro e Gemini 3.5 Flash. Il resoconto di Kabanov è datato 6 luglio 2026, il post di Checkmarx 26 luglio, e la copertura della stampa di settore si è collocata tra i due. Il benchmark a livello di repository, SusVibes, consiste in 200 attività di funzionalità in grandi repository open source, ciascuna costruita attorno a una vulnerabilità che una persona aveva già individuato e corretto; all'agente viene chiesto di implementare la funzionalità, e il successo richiede di riprodurre la protezione apportata dall'essere umano senza che gli venga mostrata.

I risultati: successo funzionale dell'83–95%, rispetto al 44–61% di una generazione precedente, ma successo in termini di sicurezza e funzionalità solo del 24–36%. Tra il 65% e il 75% delle patch che funzionavano riproducevano la debolezza che gli esseri umani avevano rimosso — la definizione di Checkmarx è CVE zombie, perché la vulnerabilità reintrodotta non ha alcun advisory né una versione da incrementare. L'esempio citato da Checkmarx è CVE-2023-29159, un bug di path traversal nel framework Starlette di Python, individuato e correttto nel 2023 e ricreato da un agente nel 2026.

Le mitigazioni sono istruttive quanto il titolo principale. Un'istruzione generica a seguire le migliori pratiche di sicurezza ha aggiunto da 1 a 8 punti. Un maggiore sforzo di ragionamento non ha aggiunto sicurezza e ha dimezzato il numero di soluzioni funzionanti. Un passaggio di modellazione delle minacce prima della codifica ha raggiunto il 43–49% di soluzioni sicure e funzionanti; una revisione di sicurezza a posteriori ha raggiunto il 47–56%, con un costo in token rispettivamente circa doppio e due volte e mezzo. Persino la variante migliore ha lasciato insicuro circa metà dei compiti, e nei casi di fallimento gli agenti a volte indicavano la difesa corretta nelle proprie note e rilasciavano comunque il codice vulnerabile.

Kabanov e Checkmarx precisano entrambi che la cifra del 65–75% va considerata con cautela: le attività sono state scelte perché realizzare la funzionalità nel modo naturale reintroduce la vulnerabilità, quindi il tasso nel codice ordinario è probabilmente inferiore — pur sostenendo che le basi di codice reali sono piene proprio di funzionalità di questo tipo, ed è proprio da lì che nascono in primo luogo le CVE.

I due studi non dovrebbero essere sommati insieme. Uno chiede se un agente può scrivere una patch per un bug specifico, già corretto. L'altro chiede se un agente che implementa una funzionalità eviterà di ricreare un bug di cui nessuno gli ha parlato. 26,0% e 24–36% sono tassi su denominatori diversi, e nessuno dei due è un tasso per il patching tramite AI in generale.

Trail of Bits: il titolo misura la configurazione sbagliata

Timeline card: July 2026 the Checkmarx-commissioned study is published; 6 August 2026 the Off-by-1 Labs report and blog are published; 7 September 2026 Japan's IPA summarises both studies in its August AI security bulletin; 15 September 2026 Trail of Bits publishes its rebuttal; 26 October 2026 1Password updates the blog with post-publication feedback.

Il 15 settembre 2026, sei settimane dopo il rilascio di 1Password, quattro ricercatori di Trail of Bits — Anish Naik, Dan Guido, Benjamin Samuels e Marcelo Morales — hanno pubblicato una replica sostenendo che la cifra del 26% non descrive le normali attività di patching. I loro argomenti, nei loro stessi numeri: due prompt dicono agli agenti di applicare la correzione sbagliata, e questi prompt rappresentano il 22% dei dati; una modalità di valutazione impedisce agli agenti di compilare o eseguire codice, e rappresenta il 36%; le sei vulnerabilità sono state scelte perché le loro correzioni erano complesse, con risultati per target dal 3% al 60% e un errore standard non divulgato di circa nove punti sulla media dei sei target; e entrambi i modelli sono stati eseguiti con i valori predefiniti anziché con il massimo sforzo.

Attaccano anche il sistema di valutazione. Sostengono che la regola di arresto e i criteri di valutazione siano in conflitto; modifiche comportamentali intenzionali sono state penalizzate come regressioni nell'8% dei verdetti ActiveMQ; e il giudice automatizzato concordava con i revisori umani sull'esito completo a cinque vie solo nel 65,9% dei casi. Citano le 248 patch Copy Fail contenenti l'off-by-one upstream intermedio rispetto alle 24 rilevate dal valutatore, e un caso Chromium in cui il valutatore ha accettato riparazioni che lasciavano ancora un use-after-free in una callback. Quelle cifre sono di 1Password stessa; il disaccordo riguarda ciò che implicano.

La loro rianalisi mantiene solo le prove in cui gli agenti potevano eseguire codice e non veniva loro indicata una riparazione errata, e scarta le esecuzioni giudicate come aventi consultato la correzione upstream. Su quel sottoinsieme, 2.634 delle 3.067 patch — l’86% — hanno bloccato l’exploit fornito. Sono cauti su ciò che questo significa: bloccare l’exploit in esame non è prova di una riparazione completa e priva di regressioni. Come baseline umana indicano 2.265 prime correzioni su 236 delle loro stesse valutazioni dal 2024 al 2026, delle quali 283 (12,5%, intervallo di confidenza al 95% dal 10,5% al 14,5%) non sono riuscite a risolvere completamente il problema. Contano inoltre 186 pull request nel loro programma Patch the Planet: 126 unite, delle quali 33 (26,2%) hanno richiesto una revisione rilevante per la sicurezza. E ammettono un caso in cui la critica di 1Password alla loro stessa patch era corretta — su freenginx, la loro correzione e quella indipendente del maintainer hanno introdotto lo stesso crash di pulizia.

La loro conclusione è netta: «I difensori non dovrebbero prendere sul serio il tasso di punta di 1Password come misura della capacità di applicazione delle patch tramite IA». 1Password non ha risposto loro nominandoli. Il blog afferma che il team accoglie con favore le critiche ai propri metodi e risultati, e l’aggiornamento del 26 ottobre ammette che i vincoli scelti potrebbero aver limitato eccessivamente ciò che gli strumenti potevano produrre. Il bollettino dell’IPA giapponese, che riporta il 26,0% e il 53,9% senza riserve, è stato pubblicato il 7 settembre — otto giorni prima della confutazione.

Ciò che è stabilito e ciò che è argomentato

• Stabilito: lo studio esiste, con autori citati per nome — Axel Mierczuk, Spencer Michaels e Keith Hoodlet — datato 6 agosto 2026, e i suoi conteggi di 6.480 tentativi, 400 esclusioni e 6.080 patch valutate compaiono nel paper, nel blog di 1Password e nel riepilogo IPA.

• Stabilito: la ripartizione degli esiti — 26,0% senza difetti, 20,1% che modificano il comportamento, 49,3% irrisolti e 4,5% che presentano un nuovo difetto — è la valutazione degli autori stessi, prodotta da due validatori modello i cui giudizi sono stati mediati e verificati incrociati con la revisione umana su un campione di 1.052 patch, con un accordo del 65,9% sulla classificazione a cinque livelli.

• Confermato: le regressioni specifiche — le 248 patch Copy Fail con l'off-by-one intermedio a monte, le 783 iterazioni che omettono la guardia ESN, il pattern .env in Gemini CLI, il secondo riferimento mancante in Chromium — sono le affermazioni degli autori sui propri dati, con il metodo di rilevamento descritto e il rilevatore verificato rispetto alla revisione manuale su 253 iterazioni.

• Si è discusso: se il 26% sia una descrizione equa di ciò che il patching con AI può fare. Trail of Bits afferma che i propri filtri portano le stesse patch a un blocco degli exploit dell'86% e che la configurazione non è un patching ordinario; 1Password dichiara di accogliere con favore la critica e che i propri vincoli potrebbero essere stati troppo stringenti. Entrambe le parti stanno esaminando le stesse 6,080 patch; il disaccordo riguarda quali filtri siano legittimi, e nessuna delle due ha pubblicato una replicazione che l'altra accetti.

• Non si afferma: che una qualsiasi di queste cose abbia causato danni sul campo. L'archivio non registra alcun danno reale e classifica la voce a livello informativo. Le sei vulnerabilità sono state corrette upstream prima che i test venissero eseguiti, e le patch oggetto dello studio erano proposte candidate prodotte in container, non codice integrato in quei progetti.

La domanda utile per un difensore non è a quale schieramento credere. È a cosa si riferisca il numero: il 26% di bug deliberatamente difficili in condizioni di informazioni deliberatamente miste, oppure l’86% di prove eseguibili in cui l’exploit fornito è stato bloccato. Entrambe le cifre provengono dallo stesso set di dati, e nessuna delle due è una specifica di acquisto. Ciò su cui le due parti concordano è l’avvertenza che 1Password stesso stampa nel documento — «una patch generata è un candidato, non la prova che la vulnerabilità sia stata corretta» — e questa è la parte che non richiede alcun giudizio.