Cogent riferisce che VR-1.1 ha superato le riparazioni nel 57,9% delle attività di LiveCVEBench

Cogent Security ha presentato VR-1.1 il 3 novembre 2026, riferendo che il modello per la correzione delle vulnerabilità ha prodotto riparazioni superate nel 57,9% delle 190 attività di LiveCVEBench, contro il 45,3% ciascuno di Claude Code e Codex.

L’ultima aggiunta alla famiglia VR di Cogent amplia le capacità di correzione introdotte con VR-1. La valutazione ha confrontato VR-1.1 con Claude Code basato su Claude Opus 5.5 e Codex basato su GPT-5.6-Cyber. Tutti i sistemi hanno ricevuto gli stessi input e la stessa configurazione, oltre a tre tentativi per attività; i punteggi si basavano sulla patch finale, dopo i tentativi di correzione interni.

Un benchmark incentrato sulle riparazioni efficaci

LiveCVEBench si concentra sulla correzione di vulnerabilità reali negli ambienti di sviluppo. Il suo articolo su CVE-Factory descrive un insieme di 190 attività aggiornato costantemente, che copre 14 linguaggi di programmazione e 153 repository. Il progetto del benchmark colloca gli agenti in ambienti di sviluppo reali, dove devono esplorare autonomamente le basi di codice, determinare il contesto di ciascuna vulnerabilità e implementare una correzione. Nuove CVE vengono aggiunte regolarmente.

La configurazione di Cogent forniva per ogni attività un rapporto sulla vulnerabilità e la relativa base di codice interessata. Una patch veniva considerata valida solo se superava i controlli sulle vulnerabilità e continuava a superare quelli di funzionalità. Le attività riguardano difetti di tipo injection, di controllo degli accessi, di configurazione e di sicurezza della memoria; una spiegazione convincente non basta se la modifica lascia aperto un altro percorso verso il difetto, disattiva comportamenti legittimi, causa una regressione o introduce nuove esposizioni.

Questo doppio requisito distingue una riparazione dal semplice blocco di una singola dimostrazione di attacco. Un modello deve preservare il comportamento previsto e al tempo stesso correggere la vulnerabilità, compresi i percorsi correlati che ne condividono la causa.

Il flusso di lavoro di riparazione di VR-1.1

Cogent attribuisce il risultato alla formazione sulla correzione delle vulnerabilità di sicurezza e a un sistema di test che riproduce una vulnerabilità, la corregge e poi verifica che la patch non possa essere aggirata. Quando la configurazione di esecuzione lo consente, VR-1.1 esamina il rapporto e il codice sorgente prima di scrivere una prova di concetto che attiva il difetto. In questo modo il modello può analizzare un malfunzionamento e ripetere il test dopo aver applicato la patch.

Prima di apportare una modifica mirata, il modello cerca percorsi di codice correlati che condividono la vulnerabilità. Un’analisi separata, svolta in un contesto nuovo, esamina la patch per individuare possibili aggiramenti e bug introdotti. VR-1.1 scrive anche test di regressione. Quando la convalida fallisce, l’analisi precedente e le informazioni sul fallimento guidano un nuovo tentativo.

Una riparazione in Fiber, nella pratica

Una delle esecuzioni registrate riguardava CVE-2025-48075 nel framework web Fiber. L’avviso di sicurezza del progetto spiega che un indice negativo nei dati di un modulo annidato può causare un arresto anomalo di BodyParser e mandare in crash il server, creando un rischio di negazione del servizio. Indica come interessate le versioni a partire dalla 2.52.6 e come versione corretta la 2.52.7.

VR-1.1 ha riprodotto l’arresto anomalo e aggiunto un controllo dei limiti prima dell’uso dell’indice, rifiutando gli indici negativi o eccessivi e preservando al contempo la gestione corretta dei moduli. Cogent riferisce che in seguito sono stati superati tutti e nove i controlli sulle vulnerabilità, rispetto a zero prima della correzione, mentre tutti i 12 controlli di funzionalità sono stati superati sia prima sia dopo. L’esempio proviene da un’esecuzione distinta, registrata su 182 attività, e non dalla valutazione finale su 190 attività.

Limiti della valutazione e uso in produzione

Durante la correzione, la valutazione bloccava l’accesso alla rete in uscita e non rendeva disponibili i test di valutazione di LiveCVEBench fino al termine del lavoro di ciascun agente. Queste condizioni impedivano di recuperare una correzione a monte o di usare direttamente i test di valutazione durante l’applicazione delle patch.

Cogent avverte che i dati di addestramento di entrambi i modelli di riferimento arrivano a date successive a quelle di pubblicazione delle CVE incluse nella versione attuale di LiveCVEBench; di conseguenza, i relativi avvisi e le correzioni potrebbero essere comparsi nei dati di addestramento. Indica le descrizioni delle attività in stile segnalazione dell’utente, il blocco della rete e le condizioni identiche come fattori che limitano tale vantaggio.

Nei controlli a campione di Cogent, i modelli sono riusciti a descrivere a memoria alcune vulnerabilità, ma non a riprodurre le patch esatte. L’azienda sta inoltre creando un insieme di attività basato su CVE divulgate dopo le date limite pertinenti e prevede di mantenerlo aggiornato.

LiveCVEBench verifica vulnerabilità note in ambienti isolati e il superamento dei test indica che sono stati soddisfatti i controlli forniti. Cogent afferma che per la distribuzione in produzione sono comunque necessarie una revisione e prove nell’ambiente di destinazione. Sta integrando VR-1.1 nel proprio flusso di lavoro di correzione, accompagnando ogni patch con la diagnosi, la prova di concetto e i test, affinché i revisori possano esaminarli. Il risultato del benchmark misura quindi le riparazioni verificate in condizioni controllate; l’uso in produzione dipende ancora dalla convalida delle riparazioni nell’ambiente in cui verrà eseguito il software.