Ciberseguridad

Veintiséis mil hallazgos, doscientos parches: Glasswing desborda la divulgación de vulnerabilidades

Mythos, de Anthropic, encontró 26 153 vulnerabilidades; hay 202 corregidas. Lo que Glasswing ha revelado de una divulgación diseñada al ritmo con que las personas hallan fallos.

Ilustración: una persona dormida sobre un escritorio bajo una lámpara, sepultada entre informes impresos y rodeada de tazas de café.

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:

FuenteHallazgos totalesLlegados a divulgaciónCorregidosNota
Panel de Anthropic26 153—421 «parcheados upstream» (→ 462 avisos de seguridad)Cifra del panel
Registro de divulgación de Anthropic (principal), tras la puesta al día26 1532736 (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úblicas23 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:

  1. 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.
  2. 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.
  3. 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

MecanismoSupuestoLo que lo rompe
Embargo de 90 díasLos investigadores encuentran fallos más despacio de lo que los mantenedores pueden corregirlosDescubrimientos a miles al mes frente a mantenedores que corrigen ~2 por proyecto
Asignación de CVEUn volumen de CVE asumible para las CNA y MITREEl programa CVE estudia automatizarse para sobrevivir al volumen
Triaje con CVSSUna persona puntúa la gravedad de cada hallazgoGravedad afirmada por el modelo; 40 puntos de diferencia con los mantenedores; métricas CVSS sin publicar
Plazos del catálogo KEV de CISAQue una vulnerabilidad esté «explotada activamente» es raro y se tramita por la vía rápidaLa 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 mantenedoresLos informes son escasos y en su mayoría correctosLa 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

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).

Artículos relacionados