Anthropic calcula por ahora en 23.019 los posibles hallazgos de vulnerabilidades que Claude Mythos, su herramienta, ha generado en proyectos de código abierto. Pero hay un dato que pesa más que ese volumen: de acuerdo con la propia compañía, solo alrededor de 1.900 informes llegaron a pasar por una revisión externa. La diferencia deja bastante claro hasta qué punto se ha disparado la búsqueda de fallos de seguridad y cómo la validación se está convirtiendo en el verdadero cuello de botella.
En otras palabras, más de 21.000 casos siguen sin validación por parte de especialistas.
Aun con eso, entre los reportes que sí se revisaron, 1.726 acabaron confirmados como vulnerabilidades reales, siempre según los datos de Anthropic. La tasa de acierto es lo bastante alta como para que fabricantes, mantenedores y equipos de respuesta le estén prestando atención.
Lo que muestran esos datos apunta a un cambio de fondo en ciberseguridad.
Durante años, encontrar vulnerabilidades era un trabajo lento y caro. Ahora el problema parece estar en otro sitio: verificar, priorizar y corregir una avalancha de avisos. Ese desplazamiento ya se nota en los flujos de trabajo habituales de los mantenedores de proyectos, los equipos internos de seguridad y los programas de recompensas por fallos.
En la práctica, todos ellos están recibiendo un volumen mucho mayor de reportes. Muchos parecen plausibles, sí, pero eso no los convierte automáticamente en urgentes ni en casos fáciles de reproducir.
Eso obliga a invertir más tiempo en clasificar que en buscar. Y encaja, además, con una tendencia más amplia del mercado: en los dos años anteriores a junio de 2026, las divulgaciones mensuales de CVE crecieron un 145 %, al mismo tiempo que se expandían las herramientas automatizadas para detectar fallos.
Donde más se ve que hace falta contexto es en la gravedad que se asigna a los hallazgos.
Según los datos revisados por Anthropic, de 27 vulnerabilidades que obtuvieron un identificador CVE, 13 habían recibido una severidad que, tras la revisión humana, se consideró demasiado alta.
En concreto, Claude Mythos etiquetó 8 de esos fallos como críticos, pero solo 1 mantuvo esa categoría después del análisis de expertos. Los demás se rebajaron cuando se tuvieron en cuenta las condiciones reales de explotación, los requisitos de privilegios o escenarios demasiado limitados como para representar un riesgo inmediato.
Uno de los ejemplos que citaron los mantenedores fue un problema en Temporal Server.
Claude Mythos marcó ese fallo en Temporal Server como crítico, pero la evaluación posterior lo dejó en severidad baja porque explotarlo exigía condiciones muy concretas y un nivel de acceso poco habitual.
La reacción en la industria, mientras tanto, es desigual.
Hay investigadores de seguridad que ven este aumento de capacidad como un avance serio: encontrar más fallos reales en menos tiempo puede ayudar a reforzar el ecosistema de código abierto. Pero también está creciendo la preocupación por la sobrecarga operativa. Si los reportes entran más deprisa de lo que pueden revisarse, los equipos corren el riesgo de quedar enterrados bajo hallazgos repetidos, mal priorizados o presentados con una gravedad inflada. Y eso puede frenar la respuesta a los casos de verdad críticos, además de meter todavía más presión sobre los programas de bug bounty.
Por ahora, las herramientas automatizadas están demostrando un valor enorme para sacar a la luz fallos reales, pero la última palabra la sigue teniendo el criterio humano.
Lo que todavía no se sabe es si la capacidad de validación va a crecer al mismo ritmo que la detección automatizada.
