Los 500 días cero de Claude Opus 4.6: qué muestran tres parches

El 5 de febrero de 2026, el Frontier Red Team de Anthropic publicó una investigación en la que informaba que Claude Opus 4.6, lanzado ese mismo día, había encontrado y validado más de 500 vulnerabilidades de alta gravedad en software de código abierto — sin herramientas específicas para la tarea, andamiaje personalizado ni indicaciones especializadas. Tres hallazgos se describen en detalle: una comprobación de límites de pila ausente en Ghostscript, una serie no verificada de llamadas a strcat en OpenSC, y un desbordamiento de búfer en el codificador GIF CGIF que depende de cómo se comporta la compresión LZW cuando su diccionario se llena. Anthropic afirma que los tres ya han sido parcheados por sus mantenedores y, según su versión, los errores se encontraron, validaron y reportaron. Muchos de los proyectos están mantenidos por equipos pequeños o voluntarios sin personal de seguridad dedicado, señala la publicación, por lo que la carga de reportar y parchear recayó sobre ellos. La propia entrada del archivo para el hallazgo, clasificada con severidad info y sin daños reales registrados, se encuentra en el Orca AI Incident Archive junto a los demás registros de políticas y divulgación de febrero de 2026.

Lo que Anthropic publicó realmente

La publicación se titula «Evaluar y mitigar el creciente riesgo de las vulnerabilidades de día cero descubiertas por LLM» y se atribuye al Frontier Red Team: Nicholas Carlini, Keane Lucas y Evyatar Ben Asher como contribuyentes por igual, junto con Newton Cheng, Hasnain Lakhani, David Forsythe y Kyla Guru. La página tiene una fecha de publicación del 5 de febrero de 2026 y una nota de edición del 6 de febrero de 2026 que registra que se actualizó la lista de autores. El archivo cita la publicación en red.anthropic.com, que ahora redirige a anthropic.com/research/zero-days.

El método importa más que la cifra principal. Anthropic dice que colocó el modelo dentro de una máquina virtual con acceso a las últimas versiones de proyectos de código abierto, y le dio utilidades estándar y las herramientas que usaría un investigador de seguridad humano —depuradores y fuzzers—, pero no instrucciones sobre cómo usarlas y, en palabras de la publicación, «ningún arnés personalizado que le habría dado conocimiento especializado sobre cómo encontrar mejor las vulnerabilidades». Lo que se estaba probando era el comportamiento del modelo tal como viene de fábrica.

El equipo redujo la búsqueda a errores de corrupción de memoria, con el razonamiento de que un fallo es más fácil de confirmar que un error lógico. Anthropic deja claro que esto es un filtro, no una garantía: "no todas las entradas que hacen que un programa se caiga son vulnerabilidades de alta gravedad". Así que los fallos volvieron al modelo para que los criticara, los deduplicara y los repriorizara, y luego pasaron a las personas. "Para nuestra ronda inicial de hallazgos, nuestros propios investigadores de seguridad validaron cada vulnerabilidad y escribieron los parches a mano. A medida que creció el volumen de hallazgos, incorporamos investigadores de seguridad externos (humanos) para ayudar con la validación y el desarrollo de parches." La automatización de parches, según la publicación, todavía se estaba construyendo.

Tres errores y los parches que siguieron

Los tres ejemplos resueltos comparten un patrón: una herramienta automatizada ya había fallado, y el modelo encontró el error razonando sobre algo distinto de la mutación de la entrada.

• Ghostscript, el intérprete de PostScript y PDF. El fuzzing y después el análisis manual no revelaron nada. El modelo leyó entonces el historial de Git del proyecto, encontró un commit que en la publicación se describe como el que añadía "comprobación de límites de pila para valores de mezcla MM" a los charstrings de Tipo 1, razonó que el código anterior a ese commit había sido vulnerable y se puso a buscar otros puntos de llamada que no habían recibido el mismo tratamiento. Encontró uno en gdevpsfx.c —la publicación cita la línea 292— y creó un archivo que provoca un fallo del programa. El repositorio lo confirma: el commit 87486fb801 de Chris Liddell, con fecha del 5 de septiembre de 2025, se titula "Charstrings de Tipo 1: añadir comprobación de límites de pila para valores de mezcla MM". Una corrección posterior de Ken Sharp, el commit 4e392a82 con fecha del 26 de enero de 2026, añade comprobaciones de límites justo antes de esa llamada en el convertidor de fuentes, registrada contra el error 709080, cuyo informe se titula "Corrección incompleta de Ghostscript para la comprobación de límites de pila de mezcla MM de Tipo 1". Un commit del 13 de febrero de 2026 amplió las comprobaciones de límites en el mismo convertidor. Ninguno de los mensajes de commit indica quién informó del error.

• OpenSC, una utilidad de línea de comandos para datos de tarjetas inteligentes. Aquí el modelo buscó llamadas a funciones de riesgo y encontró sucesivas operaciones strcat que escribían en un búfer filename de 4096 bytes, tras un cálculo de tamaño que restaba la longitud de una cadena de entrada pero luego añadía más cadenas sin volver a comprobar. La publicación señala que los fuzzers existentes rara vez llegaban a esa ruta debido a las precondiciones implicadas. El commit 33ab343a5c de OpenSC, del 19 de enero de 2026, añadió una comprobación de que la cadena añadida tiene exactamente 64 bytes, y la pull request #3554, fusionada el 25 de enero de 2026, sustituyó las llamadas restantes a strcat en todo el proyecto por strlcat; su autor calificó la función de "imán para cualquier herramienta de análisis estático y CVE".

• CGIF, un codificador GIF. La biblioteca asumía que los datos comprimidos siempre serían más pequeños que la entrada sin comprimir, lo cual es casi siempre cierto. El modelo razonó que LZW construye un diccionario de tamaño fijo y que, cuando el diccionario se llena, los códigos de borrado insertados en el flujo pueden hacer que la salida "comprimida" sea más larga que la entrada, por lo que un búfer dimensionado para N+2 códigos podría recibir más de N+1. La publicación dice que incluso una cobertura de líneas y ramas del 100 por ciento podría no exponer esto, porque requiere una secuencia particular de operaciones. La pull request #84 de CGIF, fusionada el 19 de enero de 2026 y publicada el mismo día como v0.5.1, corrige precisamente eso: "Los códigos de borrado de reinicio faltaban en el cálculo del límite superior del tamaño de los datos LZW."

Esas correcciones se aplicaron antes de que se publicara la investigación —CGIF y OpenSC el 19 de enero de 2026, OpenSC de nuevo el 25 de enero, Ghostscript el 26 de enero— y Anthropic dijo en la publicación que había «empezado a informar de ellos y estamos viendo cómo se aplican nuestros parches iniciales» antes de hacerlo público. Los repositorios registran los cambios de código; no registran quién presentó los informes, por lo que el vínculo entre los hallazgos del modelo y estos commits en particular se basa en la versión de Anthropic y en cuán estrechamente coinciden los defectos descritos con los diffs.

The researcher who said the OpenSC bug was not real

Public scrutiny of the individual findings did not start and end with Anthropic. On 14 February 2026 K. Reid Wightman, an industrial security researcher posting as @reverseics on infosec.exchange, published a review of the OpenSC example arguing the bug could not be triggered: the input string was already checked to be 64 bytes at line 5138, he wrote, which capped the buffer at 4095 bytes including the terminator. "I spent about an hour looking at the code to debunk their finding," he wrote.

He edited the same post on 17 February 2026 to withdraw the challenge. "Looks like the version of code I was looking at, already had a fix for anthropic-discovered bug(s)," the edit reads, before conceding the arithmetic: "but yes without the strlen() check on 'fp' the overflow could actually be triggered. The humble pie has been eaten." The check he had relied on was the one added to OpenSC on 19 January 2026 — before Anthropic published, and before most readers would have gone looking. The archive does not flag the record as disputed, and here the challenge was retracted by the person who raised it.

OpenSC's own maintainers answered the same question in their tracker. In discussion #3575, opened on 17 February 2026 by a user asking whether Anthropic's claims were legitimate, OpenSC maintainer frankmorgner replied the same day: "We received two bug reports from anthropic, which were both verified by humans." He said the fixes were in pull request #3554 and would be in the next release, and that commit 33ab343 was "a change that was introduced after anthropic reported the problem."

La mitad de gobernanza: sondas, bloqueo y 90 días

Lo que convierte esto en un documento de política y no en una simple nota de investigación es la segunda mitad de la publicación. Junto con el lanzamiento del modelo, Anthropic afirma que introdujo, específicas para ciberseguridad, sondas que miden las activaciones dentro del modelo mientras genera una respuesta, y que actualizó sus flujos de trabajo de aplicación para usar detección basada en sondas. Va más allá de la detección: «podemos instituir intervención en tiempo real, incluido el bloqueo del tráfico que detectemos como malicioso». Anthropic admite el costo —«Esto generará fricción para la investigación legítima y parte del trabajo defensivo»— y dice que quiere trabajar con la comunidad de investigación en seguridad en esto. No se publica ninguna tasa de detección, tasa de error ni proceso de apelación.

La publicación también sostiene que el calendario de divulgación en sí mismo es ahora un problema. «Las ventanas de 90 días estándar del sector podrían no resistir la velocidad y el volumen de los fallos descubiertos por LLM», afirma, y advierte que los modelos «podrían pronto superar la velocidad y la escala incluso de investigadores humanos expertos». Se trata de un proveedor que sostiene que la norma con la que se le juzgará necesita ser reemplazada, y es la parte del registro con mayor alcance.

¿Qué cambió después?

El 20 de febrero de 2026, Anthropic abrió Claude Code Security como una vista previa de investigación limitada para clientes de Enterprise y Team, con acceso acelerado gratuito para mantenedores de código abierto: la capacidad se comercializó quince días después de la investigación. VentureBeat informó del lanzamiento y dijo que había pedido a Anthropic la tasa de falsos positivos antes y después de la autoverificación, el número de vulnerabilidades divulgadas con parches aplicados frente a las que seguían en triaje, y las salvaguardas que distinguen el uso por parte de atacantes del uso por parte de defensores; informó que el investigador principal del proyecto no estaba disponible y que la empresa se negó a compartir mecanismos específicos de detección de atacantes.

Los parches también seguían moviéndose, y no siempre en una misma dirección. La corrección de CGIF para la asignación que describió Anthropic se publicó en la v0.5.1 el 19 de enero de 2026; el 21 de febrero de 2026, la solicitud de extracción #103 corrigió un desbordamiento de entero de 32 bits introducido por ese mismo cálculo de asignación, publicada como v0.5.2 al día siguiente para GIF de 65.535 por 65.535 píxeles como máximo. Reparar un cálculo de límites resulta ser, a su vez, una pequeña fuente de errores de límites.

Leyendo el número correctamente

La propia frase de Anthropic es «más de 500 vulnerabilidades de alta gravedad». Axios, al que la empresa informó primero, las describió el día de la publicación como «más de 500 vulnerabilidades de día cero antes desconocidas», cada una validada por un miembro del equipo de Anthropic o por un investigador de seguridad externo. Ambas descripciones apuntan al mismo conjunto, pero solo una es la redacción del proveedor, y ninguna va acompañada de una lista, una correspondencia con CVE ni una distribución de gravedad. El recuento es de Anthropic, las calificaciones de gravedad son de Anthropic, y los tres proyectos abordados en la publicación son los únicos que el público puede verificar.

El análisis independiente que siguió aceptó en gran medida la cifra sin cuestionarla y debatió sobre lo que significa. Mitch Ashley, de Futurum Group, escribió el 24 de febrero de 2026 que el resultado «importa más por lo que revela el método que por el recuento», y que la verdadera limitación está aguas abajo: «Sacar a la luz más vulnerabilidades más rápido no reduce la superficie de ataque. Crea una cola más grande ante un proceso posterior que no puede absorber el volumen». Se trata de una crítica al canal de divulgación más que al hallazgo, y coincide con el mismo punto que Anthropic planteó sobre las ventanas de 90 días.

Lo que el registro no establece

El archivo califica este registro con confianza A, gravedad informativa, sin daños reales registrados y sin marca de disputa. Esa calificación tiene que ver con lo bien documentado que está el evento, no con lo bien auditada que esté la afirmación subyacente, y vale la pena aferrarse a la diferencia. Nadie fuera de Anthropic ha verificado los 500. No se ha publicado ninguna tasa de falsos positivos. Los parches de los tres proyectos nombrados son reales y se pueden fechar, y son la corroboración más sólida disponible — pero corroboran tres ejemplos, no el total.

Lo que queda, entonces, es un anuncio bien documentado con un núcleo comprobable y un resto no comprobable: un proveedor que informa de una capacidad, tres diffs upstream que coinciden con su descripción de los errores y una intención declarada de controlar el uso indebido de esa capacidad en la capa del modelo. El archivo lo clasifica como política, que es el estante correcto. La afirmación sobre la capacidad la resolverá quien publique el cuarto parche.