Cogent informa que VR-1.1 supera las pruebas de reparación en el 57,9% de las tareas de LiveCVEBench

Cogent Security presentó VR-1.1 el 3 de noviembre de 2026 e informó que el modelo de reparación de vulnerabilidades produjo reparaciones que superaron las pruebas en el 57,9 % de las 190 tareas de LiveCVEBench, frente al 45,3 % de Claude Code y al 45,3 % de Codex.

La incorporación más reciente a la familia VR de Cogent amplía las capacidades de corrección introducidas con VR-1. En la evaluación se comparó VR-1.1 con Claude Code ejecutando Claude Opus 5.5 y con Codex ejecutando GPT-5.6-Cyber. Todos los sistemas recibieron las mismas entradas y la misma configuración, y dispusieron de tres intentos por tarea; las puntuaciones se basaron en el parche final, después de los intentos internos de reparación.

Un banco de pruebas centrado en reparaciones funcionales

LiveCVEBench se centra en corregir vulnerabilidades reales en entornos de desarrollo. El artículo sobre CVE-Factory describe un conjunto de 190 tareas, actualizado continuamente, que abarca 14 lenguajes de programación y 153 repositorios. El proyecto del banco de pruebas sitúa a los agentes en entornos de desarrollo reales, donde deben explorar bases de código de forma autónoma, establecer el contexto de cada vulnerabilidad e implementar una solución. Se añaden nuevas CVE con regularidad.

La configuración de Cogent proporcionó un informe de vulnerabilidad y la base de código afectada para cada tarea. Un parche solo se consideró válido si superaba las comprobaciones de vulnerabilidad y seguía superando las comprobaciones de funcionalidad. Las tareas abarcan fallos de inyección, control de acceso, configuración y seguridad de memoria, por lo que una explicación convincente no basta si el cambio deja otra vía para explotar el fallo, desactiva funciones legítimas, provoca una regresión o crea una nueva exposición.

Este doble requisito distingue una reparación de la mera interrupción de una demostración concreta de un ataque. El modelo debe preservar el comportamiento previsto mientras corrige la vulnerabilidad, incluidas las rutas relacionadas que comparten el mismo fallo.

El flujo de reparación de VR-1.1

Cogent atribuye el resultado a la formación en reparación de vulnerabilidades y a un sistema de pruebas que reproduce un fallo, aplica un parche y luego comprueba si es posible eludirlo. Cuando la configuración de ejecución lo permite, VR-1.1 examina el informe y el código fuente antes de redactar una prueba de concepto que activa el fallo. Así, el modelo dispone de un error que puede rastrear y de una prueba que puede volver a ejecutar después de aplicar el parche.

Antes de realizar un cambio específico, el modelo busca rutas de código relacionadas que compartan la vulnerabilidad. Una revisión independiente, en un contexto nuevo, examina el parche para detectar posibles formas de eludirlo y errores introducidos por el cambio. VR-1.1 también escribe pruebas de regresión. Si la validación falla, el análisis previo del modelo y la información sobre el fallo orientan un nuevo intento.

Una reparación en Fiber, en la práctica

Una de las ejecuciones registradas abordó la CVE-2025-48075, que afecta al framework web Fiber. El aviso de seguridad del proyecto señala que un índice negativo en datos de formularios anidados puede provocar un pánico en BodyParser y bloquear un servidor, lo que genera un riesgo de denegación de servicio. El aviso indica que las versiones a partir de la 2.52.6 están afectadas y que la 2.52.7 es la versión corregida.

VR-1.1 reprodujo el bloqueo y añadió una comprobación de límites antes de usar el índice; así, rechazó los índices negativos o excesivos y conservó el procesamiento válido de formularios. Cogent informa que, después del cambio, se superaron las nueve comprobaciones de vulnerabilidad, frente a ninguna antes, mientras que las 12 comprobaciones de funcionalidad se superaron tanto antes como después. El ejemplo procedía de una ejecución registrada independiente, de 182 tareas, y no de la evaluación final de 190 tareas.

Límites de la evaluación y uso en producción

Durante la reparación, la evaluación bloqueó el acceso a redes externas y mantuvo ocultas las pruebas de evaluación de LiveCVEBench hasta que cada agente terminó. Estas condiciones impidieron recuperar una solución previa disponible públicamente o utilizar directamente las pruebas de evaluación durante la reparación.

Cogent advierte que ambos modelos de referencia tienen fechas de corte de entrenamiento posteriores a las fechas de publicación de las CVE incluidas en la versión actual de LiveCVEBench, lo que significa que sus avisos y soluciones podrían haber aparecido en los datos de entrenamiento. La empresa señala como límites de esa ventaja las descripciones de las tareas, redactadas al estilo de informes de usuarios, el bloqueo de la conexión de red y las condiciones idénticas.

En las comprobaciones puntuales de Cogent, los modelos pudieron describir de memoria algunas vulnerabilidades, pero no reprodujeron los parches exactos. La empresa también está creando un conjunto de tareas basado en CVE divulgadas después de las fechas de corte pertinentes y tiene previsto mantenerlo actualizado.

LiveCVEBench evalúa vulnerabilidades conocidas en entornos aislados, y superar la evaluación significa cumplir las comprobaciones proporcionadas. Cogent afirma que, para desplegar la solución en producción, todavía se necesitan una revisión y pruebas en el entorno de destino. La empresa está incorporando VR-1.1 a su flujo de trabajo de corrección; cada parche incluye el diagnóstico correspondiente, una prueba de concepto y pruebas para que los revisores puedan examinarlos. Por tanto, el resultado del banco de pruebas mide reparaciones verificadas en condiciones controladas; el uso en producción sigue dependiendo de validar esas reparaciones en el entorno donde se ejecutará el software.