Cogent indique que VR-1.1 réussit 57,9% des tâches de LiveCVEBench

Cogent Security a présenté VR-1.1 le 3 novembre 2026, indiquant que ce modèle de réparation des vulnérabilités avait produit des correctifs validés pour 57,9 % des 190 tâches de LiveCVEBench, contre 45,3 % pour Claude Code et 45,3 % pour Codex.

Le dernier modèle de la famille VR de Cogent étend les capacités de correction introduites avec VR-1. Son évaluation a comparé VR-1.1 à Claude Code exécutant Claude Opus 5.5 et à Codex exécutant GPT-5.6-Cyber. Chaque système a reçu les mêmes entrées et la même configuration, ainsi que trois tentatives par tâche. Les scores reposaient sur le correctif final, après les tentatives de réparation internes du système.

Un benchmark axé sur des réparations fonctionnelles

LiveCVEBench se concentre sur la correction de vulnérabilités réelles dans des environnements de développement. Son article sur CVE-Factory décrit un ensemble de 190 tâches, régulièrement mis à jour, couvrant 14 langages de programmation et 153 dépôts. Le projet de benchmark place les agents dans de véritables environnements de développement, où ils doivent explorer des bases de code de manière autonome, déterminer le contexte de chaque vulnérabilité et mettre en œuvre un correctif. De nouvelles CVE sont ajoutées régulièrement.

Pour chaque tâche, la configuration de Cogent fournissait un rapport de vulnérabilité et la base de code concernée. Un correctif n’était considéré comme valide que si les contrôles de vulnérabilité réussissaient et que les tests fonctionnels continuaient de passer. Les tâches portent sur des failles d’injection, de contrôle d’accès, de configuration et de sécurité mémoire. Une explication convaincante ne suffit donc pas si la modification laisse une autre voie d’exploitation, désactive un comportement légitime, provoque une régression ou crée une nouvelle exposition.

Cette double exigence distingue une véritable réparation du simple fait de bloquer une démonstration d’attaque. Le modèle doit préserver le comportement prévu tout en corrigeant la faille, y compris sur les chemins connexes qui présentent la même faiblesse.

Le processus de réparation de VR-1.1

Cogent attribue ce résultat à un entraînement à la réparation des failles de sécurité et à un dispositif qui reproduit une faiblesse, la corrige, puis vérifie que le correctif ne peut pas être contourné. Lorsque la configuration d’exécution le permet, VR-1.1 examine le rapport et le code source avant de rédiger une preuve de concept qui déclenche la faille. Le modèle dispose ainsi d’un problème à analyser et d’un test à relancer après l’application du correctif.

Avant d’effectuer une modification ciblée, le modèle recherche les chemins de code connexes qui présentent la même faiblesse. Une vérification distincte, dans un contexte vierge, examine le correctif pour détecter d’éventuels contournements et les bogues qu’il aurait introduits. VR-1.1 rédige également des tests de non-régression. Lorsque la validation échoue, son analyse précédente et les informations sur l’échec orientent une nouvelle tentative.

Exemple concret de réparation dans Fiber

Une exécution consignée portait sur CVE-2025-48075 dans le framework web Fiber. L’avis de sécurité du projet indique qu’un indice négatif dans des données de formulaire imbriquées peut provoquer une panique dans BodyParser et faire planter un serveur, créant ainsi un risque de déni de service. Il précise que les versions à partir de 2.52.6 sont concernées et que la version 2.52.7 est la version corrigée.

VR-1.1 a reproduit le plantage et ajouté une vérification des limites avant l’utilisation de l’indice, rejetant les indices négatifs ou trop élevés tout en préservant le traitement des formulaires valides. Cogent indique que les neuf contrôles de vulnérabilité ont réussi après la correction, contre zéro auparavant, tandis que les 12 contrôles fonctionnels ont réussi avant comme après. Cet exemple provient d’une exécution distincte consignée, portant sur 182 tâches, et non de l’évaluation finale de 190 tâches.

Limites de l’évaluation et utilisation en production

L’évaluation bloquait l’accès au réseau externe pendant les réparations et ne communiquait les tests de notation de LiveCVEBench qu’une fois chaque agent arrivé au terme de son travail. Ces conditions empêchaient de récupérer un correctif en amont ou d’utiliser directement les tests de notation pendant la correction.

Cogent souligne que les dates de fin d’entraînement des deux modèles de référence sont postérieures aux dates de publication des CVE de la version actuelle de LiveCVEBench. Leurs avis de sécurité et leurs correctifs ont donc pu figurer dans leurs données d’entraînement. L’entreprise cite les descriptions de tâches rédigées sous la forme de signalements d’utilisateurs, le blocage du réseau et l’identité des conditions comme des limites à cet avantage.

Lors de vérifications ponctuelles, Cogent a constaté que les modèles pouvaient décrire de mémoire certaines vulnérabilités, mais ne reproduisaient pas les correctifs exacts. L’entreprise constitue également un ensemble de tâches à partir de CVE divulguées après les dates de fin d’entraînement concernées et prévoit de le maintenir à jour.

LiveCVEBench évalue des vulnérabilités connues dans des environnements isolés, et réussir signifie satisfaire aux contrôles fournis. Cogent précise qu’un déploiement en production nécessite toujours un examen et des tests dans l’environnement cible. L’entreprise intègre VR-1.1 à son processus de correction, chaque correctif étant accompagné du diagnostic, de la preuve de concept et des tests afin que des évaluateurs puissent les examiner. Le résultat du benchmark mesure donc des réparations vérifiées dans des conditions contrôlées ; l’utilisation en production dépend toujours de la validation de ces réparations dans l’environnement où le logiciel sera exécuté.