Las cifras de validación
Según la actualización de Glasswing publicada por Anthropic (mayo de 2026) y la system card de Mythos Preview:
- Proyectos analizados: >1000
- Hallazgos de gravedad alta o crítica comunicados: 6202
- Evaluados de forma independiente: 1752, por seis empresas de investigación en seguridad
- Validados como verdaderos positivos: 90,6 %
- Gravedad alta o crítica confirmada: 62,4 %
Son cifras sólidas, y por eso el resto de este artículo no es un desmentido. El modelo funciona. El cuello de botella está más adelante en la cadena y, como veremos, lo que se afirma sobre la gravedad es más endeble que lo que se afirma sobre la validez.
Tres registros que no cuadran
Patrick Garrity, de VulnCheck, sigue Glasswing desde su lanzamiento el 7 de abril. Este es su análisis del 8 de septiembre sobre el registro ya completado con los datos atrasados:
| Fuente | Hallazgos totales | Llegados a divulgación | Corregidos | Nota |
|---|---|---|---|---|
| Panel de Anthropic | 26 153 | — | 421 «parcheados upstream» (→ 462 avisos de seguridad) | Cifra del panel |
| Registro de divulgación de Anthropic (principal), tras la puesta al día | 26 153 | 2736 (10,5 %) | 202 (0,8 %) | 2096 divulgados sin corregir; 191 previos a la divulgación; 245 retirados; 2 duplicados |
| Subregistros CVE / GHSA | — | — | — | El registro CVE recoge 70 CVE; el principal, 82. El registro GHSA recoge 49; el principal, 77. |
| Seguimiento de VulnCheck a partir de fuentes públicas | 23 019 candidatos (jul.) | 1596 llegaron a los mantenedores (jun.) | 126 CVE publicados; 1 con explotación activa confirmada (jul.) | Independiente |
El resumen del propio Garrity merece citarse y es justo: los números «sencillamente no cuadran». Sus observaciones concretas:
- Solo el 9,8 % de los hallazgos ha llegado a un mantenedor al cabo de cinco meses. Anthropic lo reconoce en el propio registro: el triaje y la revisión humanos son «el paso limitante».
- Los 202 hallazgos corregidos se reparten entre 113 proyectos: 1,79 correcciones por proyecto. El registro contiene más hallazgos retirados o duplicados que corregidos.
- La discrepancia entre 421 y 202 probablemente se deba a una cuestión de definición (parcheado upstream frente a corrección confirmada en el registro). Pero la razón de ser de un registro de divulgación es precisamente ser la cifra oficial. Dos cifras de una misma organización son un problema de gobernanza, no de redondeo.
- Las fechas engañan. El registro solo ha tenido dos actualizaciones masivas, así que la «fecha de revelación pública» de un hallazgo no es la fecha en que apareció realmente.
La diferencia de gravedad: cuando «crítico» carga con demasiado peso
La novedad más importante del registro de septiembre es que ahora muestra tanto la gravedad que asigna Claude como la que asigna el mantenedor. Y divergen mucho:
- Claude calificó el 91,5 % de los hallazgos como críticos o altos.
- Los mantenedores calificaron como críticos o altos el 51,3 % de esos mismos hallazgos.
Son 40 puntos de diferencia, y como el registro no publica las métricas CVSS en las que se basan las puntuaciones de Claude, la causa de fondo no se puede auditar desde fuera. La lectura de Garrity: probablemente el modelo hace «una valoración genérica, y no la que saldría de un prompt bien elaborado, escrito por alguien experto en gravedad». Esto importa porque el titular de las «miles de vulnerabilidades críticas» se apoya en la puntuación de gravedad del modelo, y los mantenedores, responsables del código, la reducen más o menos a la mitad.
El caso de curl: por qué ese «91,4 % de verdaderos positivos» necesita un asterisco
Daniel Stenberg (mantenedor de curl) documentó los hallazgos de Mythos sobre curl: de cinco hallazgos comunicados, quedó uno. Tres eran falsos positivos, uno era un fallo pero no una vulnerabilidad y uno era una vulnerabilidad real. Los datos del registro encajan con este patrón. Una tasa alta de verdaderos positivos validados en una muestra evaluada de forma independiente puede convivir con una experiencia mucho más caótica para el mantenedor que recibe los hallazgos en bruto, porque la deduplicación, el análisis de alcanzabilidad y la pregunta de «¿esto es de verdad una vulnerabilidad o solo un fallo?» son justo los pasos de triaje humano en los que se atasca el proceso.
Por qué un hallazgo embargado que envejece es un pasivo
Un hallazgo bajo embargo solo es un activo mientras sea exclusivo. Hay tres cosas que lo erosionan:
- El redescubrimiento independiente. Otros corrigieron 18 hallazgos antes de que Anthropic los comunicara. Garrity: «Sospecho que este problema irá a más con el tiempo, a medida que los hallazgos envejezcan y los mantenedores u otros investigadores los encuentren y los corrijan por su cuenta». Cada nuevo modelo capaz —y cada atacante que utilice uno— aumenta la tasa de redescubrimiento. El benchmark de redescubrimiento de la UCL (véase Lo que Mythos encontró realmente) mide exactamente esto.
- La superficie de filtración. Hay 2096 hallazgos comunicados al mantenedor pero aún sin corregir. Cada uno lo conocen al menos dos partes, además de cualquiera que tenga acceso al buzón o al gestor de incidencias del mantenedor.
- La exposición a su propia política. Como autoridad de numeración CVE (CVE Numbering Authority) para los hallazgos de Glasswing, Anthropic está sujeta al plazo que ella misma ha fijado (publicación a los 90 días, espera de 45 días tras el parche, prórrogas de 14 días, excepciones más amplias: en la práctica, no está claro cuándo vence). En junio, VulnCheck ya contaba 10 hallazgos sin divulgar que habían superado los 90 días y 168 a punto de superarlos. Los hallazgos que pasan el plazo sin publicarse cuestan credibilidad; publicarlos sin parche cuesta seguridad. Con 24 000 hallazgos en cola, la política obliga a tomar una decisión para la que no se redactó.
Los supuestos ocultos de la divulgación coordinada
| Mecanismo | Supuesto | Lo que lo rompe |
|---|---|---|
| Embargo de 90 días | Los investigadores encuentran fallos más despacio de lo que los mantenedores pueden corregirlos | Descubrimientos a miles al mes frente a mantenedores que corrigen ~2 por proyecto |
| Asignación de CVE | Un volumen de CVE asumible para las CNA y MITRE | El programa CVE estudia automatizarse para sobrevivir al volumen |
| Triaje con CVSS | Una persona puntúa la gravedad de cada hallazgo | Gravedad afirmada por el modelo; 40 puntos de diferencia con los mantenedores; métricas CVSS sin publicar |
| Plazos del catálogo KEV de CISA | Que una vulnerabilidad esté «explotada activamente» es raro y se tramita por la vía rápida | La IA de Microsoft convirtió 182 de 200 fallos del kernel en PoC a 3,61 dólares cada uno (véase Black Hat 2026: lo que defendieron las ponencias principales) |
| Buena fe de los mantenedores | Los informes son escasos y en su mayoría correctos | La avalancha de informes de IA de baja calidad precedió a Glasswing |
Qué se supone que debe hacer un mantenedor con 400 hallazgos
Siendo sinceros, no lo que le pide el sistema actual. Estas son las propuestas que hay sobre la mesa, ordenadas más o menos según cuánto cambian las cosas:
- Agrupar, deduplicar y priorizar en origen. El caso de curl muestra por qué: el 5→1 debería producirse antes de que el mantenedor vea nada. Las 245 retiradas del registro son triaje que ha acabado recayendo en personas.
- Que quien encuentra el fallo aporte el parche. Si es capaz de escribir un exploit, normalmente también puede escribir una corrección; el trabajo del mantenedor pasa a ser revisar. Esto desplaza el cuello de botella, no lo elimina, y plantea el problema de «el modelo avala su propio parche», que salió a la luz por otro lado este verano.
- Corregir clases enteras de fallos en vez de casos sueltos (el argumento de Weston en Black Hat; véase Black Hat 2026: lo que defendieron las ponencias principales): 400 fallos de seguridad de memoria no son 400 parches.
- Escalonar el embargo según la capacidad del proyecto. Un plazo de 90 días no significa lo mismo para un proveedor con muchos recursos que para un proyecto de dos personas.
- Financiar el triaje. Las donaciones de Anthropic (2,5 millones de dólares a Alpha-Omega a través de OpenSSF/Linux Foundation y 1,5 millones de dólares a la Apache Software Foundation), más 100 millones de dólares en créditos de API para sus socios, son un comienzo. La distancia entre eso y el trabajo que suponen 24 000 hallazgos sin divulgar es la verdadera cuestión política.
Fuentes
- Anthropic, anuncio de Claude Mythos Preview + Project Glasswing, 8 de abril de 2026, y actualización de Glasswing, mayo de 2026 — anthropic.com; Disclosure Ledger — red.anthropic.com
- VulnCheck (Patrick Garrity), The Anthropic Glasswing Receipts Are Starting to Trickle In, 8 de septiembre de 2026 — https://www.vulncheck.com/blog/anthropic-glasswing-receipts ; Observations on Anthropic’s Vulnerability Disclosure Ledger, 9 de junio de 2026 — https://www.vulncheck.com/blog/anthropic-ledger ; Tracking CVEs Attributed to Anthropic, 15 de abril de 2026 — https://www.vulncheck.com/blog/anthropic-glasswing-cves
- Daniel Stenberg, Mythos Finds a Curl Vulnerability, 11 de mayo de 2026 — https://daniel.haxx.se/blog/2026/05/11/mythos-finds-a-curl-vulnerability/
- Dark Reading, Mythos Vulnerability Firehose Hits a Human Bottleneck, 10 de septiembre de 2026 — https://www.darkreading.com/application-security/mythos-vulnerability-firehose-hits-human-bottleneck
- The Register, AI-found bugs aren’t proving any easier to exploit despite the hype, 28 de julio de 2026 — https://www.theregister.com/security/2026/07/28/ai-found-bugs-arent-proving-any-easier-to-exploit-despite-the-hype/5279637
- CSO Online, Project Glasswing has uncovered 10,000 vulnerabilities: Anthropic, mayo de 2026 — csoonline.com; Help Net Security, 26 de mayo de 2026 — helpnetsecurity.com
Nota editorial: no hemos podido confirmar que llegara a publicarse, como documento aparte, el informe de Glasswing a los 90 días prometido para principios de julio. Si existe, habrá que revisar el penúltimo párrafo de la lectura rápida.
Volver a la lectura rápida (3 min).