El estudio de parches de IA de 1Password: 26% de correcciones limpias, y luego una réplica

El 6 de agosto de 2026, Off-by-1 Labs de 1Password publicó un estudio de 55 páginas sobre si los agentes de programación de vanguardia pueden parchear vulnerabilidades reales. ChatGPT 5.5, ejecutándose con las salvaguardas Trusted Access for Cyber de OpenAI en esfuerzo medio, y Claude Opus 4.8, ejecutándose con las salvaguardas del Cyber Verification Program de Anthropic en esfuerzo alto, produjeron 6.480 intentos de parche contra seis errores recientemente divulgados que abarcan varios archivos. Una pasada de verificación de trampas excluyó 400 de ellos al considerar que el modelo había ido a buscar la corrección upstream; de los 6.080 restantes, el 26,0 % cerró la vulnerabilidad sin cambiar el comportamiento, y el 53,8 % dejó abierta una vía de explotación, introdujo una nueva falla o hizo ambas cosas. Ningún sistema fue vulnerado y no se expusieron datos de usuarios — la tasa de defectos está en los propios parches, por lo que el archivo clasifica la entrada con severidad info y sin daños registrados. El propio registro, con su grado de confianza y las fuentes citadas, está catalogado en el Orca AI Incident Archive, que indexa incidentes y vulnerabilidades de IA documentados.

Los seis bugs, y por qué estos seis

Los objetivos fueron elegidos para ser hostiles. Cada uno debía encontrarse en código de código abierto que el agente pudiera leer; causar un compromiso grave de confidencialidad, integridad o disponibilidad; ya estar parcheado en el upstream, con ese parche ocultado al agente y usado solo como línea base de calificación; haberse divulgado lo suficientemente recientemente como para que fuera improbable que la corrección estuviera en los datos de entrenamiento del modelo; y requerir una corrección real que tocara varios archivos, funciones o rutas de código. La divulgación más antigua entre ellos fue el 26 de marzo de 2026 y la más reciente el 12 de mayo.

Cada objetivo recibió 540 intentos por modelo: tres modos de ejecución × nueve plantillas de prompts × 20 muestras. Las ejecuciones de un solo intento no tenían shell ni red más allá de la propia API del modelo. Las ejecuciones iterativas contaban con scripts de reproducción y hasta diez pasadas, con un archivo de memoria conservado entre ellas. Las ejecuciones exploratorias tenían herramientas pero ninguna prueba proporcionada, y se les indicó que decidieran su propio curso de acción. Las plantillas abarcaban desde el informe completo de un mantenedor, pasando por un ticket SAST, hasta dos que prescribían una corrección plausible pero incorrecta. Las ejecuciones estaban aisladas en contenedores, y el historial de git se truncó en el commit inmediatamente anterior al parche real.

La hipótesis de trabajo de los autores, fijada cuando el proyecto comenzó el 20 de mayo de 2026, era que los modelos aplicarían parches a una tasa superior al 67 %. Ninguna configuración individual —modelo, modo y prompt— superó el 50 % en todos los objetivos.

El 26 % es una celda de una escala de cinco partes.

El artículo evalúa cada parche según cinco resultados. S1 mitiga todas las rutas explotables y deja sin cambios el comportamiento no relacionado, o lo cambia exactamente como lo hace el parche real de upstream. S2 mitiga la vulnerabilidad, pero en el proceso cambia el comportamiento de la aplicación —por ejemplo, rechazando una entrada benigna junto con la maliciosa—. S3 deja abierta al menos una ruta de explotación y no añade ninguna falla nueva. S4 corrige el error reportado e introduce otro distinto. S5 no cumple ninguna de las dos funciones.

A lo largo de las 6.080 iteraciones sin trampa, el artículo reporta un 26,0 % para S1 —25,6 % para Claude Opus 4.8 y 26,5 % para ChatGPT 5.5—, después un 20,1 % para S2, un 49,3 % para S3, un 2,3 % para S4 y un 2,2 % para S5. La cifra de fallos que se difunde, 53,9 %, es la combinación de S3, S4 y S5; la tabla del artículo suma 53,8 % antes del redondeo, y tanto el blog de 1Password como la fila del archivo indican 53,9 %.

Los dos modelos terminaron, en promedio, dentro de un punto porcentual entre sí, pero casi toda la variación estuvo en los objetivos y no en el modelo. Al promediar ambos, las tasas de corrección limpia por objetivo variaron desde un 3,2 % en Apache ActiveMQ hasta un 60,0 % en Exim. Solo en Exim, los dos modelos quedaron separados por 31,6 puntos: Claude Opus 4.8 con un 75,8 % y ChatGPT 5.5 con un 44,2 %. Los autores interpretan esto como una advertencia para los agentes parcheadores plug-and-play y afirman explícitamente que el estudio no es una comparación directa entre los dos modelos.

Dos cifras secundarias importan más que el titular. De los parches calificados como arreglos limpios, el 25.2% portaba una marca de fragilidad: cerraban el agujero reportado, pero dejaban la primitiva subyacente en su lugar, aunque no necesariamente alcanzable. Considerando S1 y S2 en conjunto, el 37.5% eran frágiles. Por separado, en los brazos iterativo y exploratorio, se consideró que el 9.3% de las iteraciones sometidas a verificación de trampas había consultado el parche upstream, de donde provinieron las 400 exclusiones. El costo fue modesto: $2.11 por intento para ChatGPT 5.5 y $2.81 para Claude Opus 4.8, o $4.49 y $6.44 por arreglo limpio una vez amortizados los intentos fallidos, excluido el costo de confirmar un arreglo.

La calidad de las indicaciones influyó en la tasa de correcciones limpias más de lo que lo hizo la elección del modelo. Con indicaciones de corrección cuidadosamente correctas, la tasa de S1 fue del 35,9 %; sin indicaciones, del 24,7 %; con indicaciones que nombraban la causa raíz o la dirección de corrección equivocadas, del 7,4 %. Los autores destacan esto en particular: cuando las propias llamadas a herramientas del agente contradecían la instrucción humana, a menudo seguía la instrucción de todos modos.

Cómo eran realmente los fallos

El caso más claro es CVE-2026-31431, el error AF_ALG del kernel de Linux conocido como Copy Fail. Upstream corrigió la primitiva de corrupción de memoria por mapeo cruzado en el commit a664bf3d revirtiendo la transformación a una operación fuera de sitio — e introdujo un nuevo off-by-one en la misma función auxiliar, que los mantenedores corrigieron un commit después en 31d00156, al que se asignó CVE-2026-43078. Los modelos reprodujeron la forma intermedia casi exactamente: 129 de 400 parches de ChatGPT no tramposos (32,2 %) y 119 de 383 parches de Claude (31,1 %) contenían ese off-by-one, en todos los modos. El artículo identificó esos 248 mediante una comparación estructural de la función reescrita; el evaluador automatizado solo marcó 14 parches de ChatGPT y 10 parches de Claude como responsables de introducir una nueva vulnerabilidad.

Un fallo más silencioso se encuentra en el mismo archivo. Reelaborar la ruta de descifrado de authencesn también expone una escritura del número de secuencia extendido que se sale de los límites cuando la etiqueta de autenticación tiene menos de cuatro bytes; el upstream lo corrige en 5db6ef98 al rechazar hashes de tamaño insuficiente durante la creación de la instancia. Ese defecto es anterior a Copy Fail, no figura entre los commits de corrección del CVE, y el reproductor nunca lo ejercita porque fija la longitud de la etiqueta en cuatro bytes. Las 783 iteraciones sin trampa lo dejaron sin protección, incluidos todos los parches calificados como una corrección limpia del propio Copy Fail; los únicos parches que incluían la protección eran cuatro iteraciones que habían copiado literalmente el commit de upstream.

GHSA-wpqr-6v78-jr5g, la vulnerabilidad de ejecución remota de código de Gemini CLI, es un problema de dos partes: el modo headless confía automáticamente en el espacio de trabajo y carga configuración local del espacio de trabajo, incluido un .env que inicializa el entorno del proceso, mientras que un flag separado omite la lista de permitidos de herramientas. La tasa media de corrección limpia en ambos modelos fue del 5,6 %, la más baja del estudio. En modo one-shot, el 29,4 % de los parches de ChatGPT y el 63,9 % de los de Claude dejaron de confiar automáticamente en el espacio de trabajo y siguieron cargando el .env controlado por el atacante, porque la carga del entorno ocurre en un módulo distinto del que toma la decisión de confianza. Cuando el reproductor nombró la ruta del .env, el brazo iterativo lo cerró: el punto ciego era la atención, no la capacidad.

El error de Chromium, CVE-2026-8512, es un use-after-free en el vigilante de archivos de macOS. La corrección upstream sustituye un puntero sin procesar por un contexto con recuento de referencias que debe mantenerse vivo en dos lugares: en el sitio de instalación y, de nuevo, dentro de la propia devolución de llamada. De los parches que adoptaron la arquitectura con recuento de referencias, el 41,9 % de ChatGPT y el 38,5 % de Claude mantuvieron la primera referencia y descartaron la segunda, lo que reubica el use-after-free en lugar de eliminarlo.

Estos ejemplos comparten una propiedad que importa a cualquiera que planee automatizar el bucle: a menudo el calificador no podía ver el fallo. Las calificaciones automatizadas de los modelos coincidieron con los revisores humanos en el resultado de cinco categorías el 65,9 % de las veces, en si el error original se había corregido el 87,7 % de las veces y en si había aparecido un nuevo error el 70,5 % de las veces. Los dos validadores de los modelos discreparon entre sí en el 36,8 % de los parches, y las calificaciones agrupadas muestran que Claude calificaba benévolamente a quienquiera que hubiera escrito el parche, mientras que ChatGPT calificaba con rigor.

Lo que 1Password dice que debería suceder a continuación

Keith Hoodlet, quien lidera Off-by-1 Labs, dijo a eSecurity Planet que «generar un parche no es lo mismo que corregir una vulnerabilidad» y que «la revisión humana experta sigue siendo esencial para verificar que un parche sea tanto eficaz como seguro». La conclusión del documento es más limitada que la de la mayoría de la cobertura: el éxito depende en gran medida de información precisa y de alta señal sobre el error, y seleccionar y organizar esa información es tarea de ingenieros que conocen la base de código.

El comentario de Anthropic citado en el blog es que la generación de parches ha superado la verificación de parches, que la verificación debería basarse en la ejecución en lugar de en la inspección, y que los expertos de dominio deberían seguir siendo los revisores finales con la capacidad actual de los modelos. 1Password publicó el arnés, al que calificaron de defectuoso, y los 6.480 parches, para que otros puedan probar qué comprobaciones habrían detectado los fallos. El 26 de octubre se actualizó el blog con comentarios posteriores a la publicación: las restricciones que eligió el equipo «podrían haber limitado lo que podían producir las herramientas de parcheo agéntico», y se describe como una útil próxima pregunta si una verificación más sólida cambia los resultados.

El registro también incluye un segundo estudio, y no es la misma prueba.

Una fila del archivo contiene dos conjuntos de cifras, y la Information-technology Promotion Agency de Japón es el documento que los presenta en paralelo: su boletín de seguridad de IA de agosto de 2026, publicado el 7 de septiembre, resume ambos estudios en una única entrada fechada el 6 de agosto. El segundo estudio es el de Checkmarx: encargado por Checkmarx y realizado por Ilya Kabanov, director ejecutivo de The Weather Report, quien volvió a ejecutar dos pruebas de referencia publicadas en cuatro modelos dentro de sus propios agentes de línea de comandos — Claude Opus 4.8, GPT-5.5, Gemini 3.1 Pro y Gemini 3.5 Flash. El informe de Kabanov está fechado el 6 de julio de 2026, la publicación de Checkmarx el 26 de julio, y la cobertura especializada se extendió entre ambas fechas. La prueba de referencia a nivel de repositorio, SusVibes, consta de 200 tareas de funcionalidades en grandes repositorios de código abierto, cada una centrada en una vulnerabilidad que una persona ya había encontrado y corregido; se pide al agente que implemente la funcionalidad, y el éxito requiere reproducir la protección aplicada por la persona sin que se le muestre.

Los resultados: éxito funcional del 83–95 %, frente al 44–61 % de una generación anterior, pero éxito seguro y funcional de solo el 24–36 %. Entre el 65 % y el 75 % de los parches que funcionaron reprodujeron la debilidad que los humanos habían eliminado; la expresión que usa Checkmarx para esto es la CVE zombi, porque la falla reintroducida no tiene aviso de seguridad ni versión que actualizar. El ejemplo que menciona Checkmarx es CVE-2023-29159, una vulnerabilidad de path traversal en el framework Starlette de Python, encontrada y corregida en 2023 y reconstruida por un agente en 2026.

Las mitigaciones son tan reveladoras como el titular. Una instrucción genérica de seguir las mejores prácticas de seguridad añadió de 1 a 8 puntos. Un mayor esfuerzo de razonamiento no aportó seguridad y redujo a la mitad el número de soluciones funcionales. Un paso de modelado de amenazas antes de codificar alcanzó 43–49% de soluciones seguras y funcionales; una revisión de seguridad a posteriori alcanzó 47–56%, con aproximadamente el doble y dos veces y media el coste en tokens, respectivamente. Incluso el mejor brazo dejó insegura alrededor de la mitad de las tareas, y en los fallos los agentes a veces nombraban la defensa correcta en sus propias notas y aun así entregaban el código vulnerable.

Kabanov y Checkmarx matizan ambos la cifra del 65–75 %: las tareas se eligieron porque construir la funcionalidad de la forma natural reintroduce el defecto, por lo que la tasa en código ordinario es probablemente menor — al tiempo que sostienen que las bases de código reales están llenas de exactamente ese tipo de funcionalidades, que es de donde proceden los CVE en primer lugar.

Los dos estudios no deben sumarse. Uno pregunta si un agente puede escribir un parche para un error concreto que ya estaba corregido. El otro pregunta si un agente que implementa una funcionalidad evitará volver a introducir un error del que nadie le había informado. 26.0% y 24–36% son tasas sobre denominadores diferentes, y ninguna es una tasa de parcheo con IA en general.

Trail of Bits: el titular mide la configuración equivocada

El 15 de septiembre de 2026, seis semanas después del lanzamiento de 1Password, cuatro investigadores de Trail of Bits —Anish Naik, Dan Guido, Benjamin Samuels y Marcelo Morales— publicaron una réplica en la que sostenían que la cifra del 26 % no describe la aplicación habitual de parches. Sus argumentos, en sus propias cifras: dos prompts indican a los agentes que apliquen la corrección equivocada, y esos prompts representan el 22 % de los datos; un modo de evaluación impide que los agentes compilen o ejecuten código, y representa el 36 %; las seis vulnerabilidades se eligieron porque sus correcciones eran complejas, con resultados por objetivo que van del 3 % al 60 % y un error estándar no divulgado de unos nueve puntos en el promedio de los seis objetivos; y ambos modelos se ejecutaron con sus valores predeterminados en lugar de con el máximo esfuerzo.

También atacan la calificación. Aducen que la regla de parada y los criterios de calificación entran en conflicto; los cambios de comportamiento intencionados se penalizaron como regresiones en el 8 % de los veredictos de ActiveMQ; y el juez automatizado coincidió con los revisores humanos en el resultado completo de cinco categorías solo el 65,9 % de las veces. Citan los 248 parches de Copy Fail que contenían el error de desfase por uno intermedio en upstream frente a los 24 que detectó el calificador, y un caso de Chromium en el que el calificador aceptó reparaciones que aún dejaban un uso después de liberación en una llamada de retorno. Esas cifras son de 1Password; el desacuerdo gira en torno a lo que implican.

Su reanálisis conserva solo los ensayos en los que los agentes podían ejecutar código y no se les indicó la reparación equivocada, y descarta las ejecuciones que se consideró que habían consultado la corrección upstream. En ese subconjunto, 2.634 de 3.067 parches —el 86%— bloquearon el exploit proporcionado. Son cautelosos sobre lo que eso significa: bloquear el exploit que se tiene no es prueba de una reparación completa y sin regresiones. Como referencia humana, señalan 2.265 primeras correcciones en 236 de sus propias evaluaciones de 2024 a 2026, de las cuales 283 (12,5%, intervalo de confianza del 95%: 10,5% a 14,5%) no lograron resolver por completo el problema. También contabilizan 186 pull requests en su programa Patch the Planet: 126 fusionadas, de las cuales 33 (26,2%) necesitaron una revisión relevante para la seguridad. Y admiten un caso en el que la crítica de 1Password al parche de los autores fue correcta: en freenginx, su corrección y la corrección independiente del mantenedor introdujeron el mismo fallo de limpieza.

Su conclusión es contundente: «Los Defenders no deberían tomar la tasa principal de 1Password como una medida seria de la capacidad de la IA para aplicar parches». 1Password no les respondió por su nombre. El blog afirma que el equipo acoge con agrado las críticas a sus métodos y hallazgos, y la actualización del 26 de octubre admite que las restricciones elegidas pueden haber limitado en exceso lo que las herramientas podían producir. El boletín de IPA de Japón, que recoge el 26,0 % y el 53,9 % sin matices, se publicó el 7 de septiembre, ocho días antes de la réplica.

Qué está establecido y qué se argumenta

• Establecido: el estudio existe, con autores identificados — Axel Mierczuk, Spencer Michaels y Keith Hoodlet — fechado el 6 de agosto de 2026, y sus cifras de 6.480 intentos, 400 exclusiones y 6.080 parches evaluados aparecen en el artículo, en el blog de 1Password y en el resumen de IPA.

• Establecido: la combinación de resultados —26,0 % limpios, 20,1 % que alteran el comportamiento, 49,3 % no resueltos y 4,5 % que presentan un nuevo defecto— es la propia calificación de los autores, producida por dos validadores de modelos cuyos veredictos se promediaron y se contrastaron con una revisión humana en una muestra de 1.052 parches, con una concordancia del 65,9 % en la calificación de cinco niveles.

• Establecido: las regresiones específicas — los 248 parches Copy Fail con el off-by-one intermedio en upstream, las 783 iteraciones que omiten la protección de ESN, el patrón .env en Gemini CLI, la segunda referencia faltante en Chromium — son afirmaciones de los autores sobre sus propios datos, con el método de detección descrito y el detector verificado contra revisión manual en 253 iteraciones.

• Debatido: si el 26 % es una afirmación justa de lo que puede lograr el parcheo con IA. Trail of Bits dice que sus propios filtros llevan los mismos parches a un 86 % de bloqueo de exploits y que la configuración no es parcheo convencional; 1Password dice que agradece la crítica y que sus restricciones pueden haber sido demasiado estrictas. Ambos están leyendo los mismos 6.080 parches; el desacuerdo gira en torno a qué filtros son legítimos, y ninguna de las partes ha publicado una replicación que la otra acepte.

• No se afirma: que algo de esto haya causado daños en el terreno. El archivo no registra ningún daño real y cataloga la entrada con severidad informativa. Las seis vulnerabilidades se parchearon en upstream antes de que se ejecutaran las pruebas, y los parches objeto de estudio eran candidatos producidos en contenedores, no código fusionado en esos proyectos.

La pregunta útil para un defensor no es a qué bando creer. Es de qué es una tasa el número: 26 % de errores deliberadamente difíciles con información deliberadamente mixta, o 86 % de pruebas ejecutables en las que se bloqueó el exploit suministrado. Ambas cifras proceden del mismo conjunto de datos, y ninguna es una especificación de adquisición. En lo que ambas partes sí coinciden es en la advertencia que 1Password imprime en el artículo —«un parche generado es un candidato, no una prueba de que la vulnerabilidad esté corregida»—, y esa es la parte que no necesita adjudicación.