Anthropic ha publicado un panel abierto con los resultados de su programa de divulgación coordinada de vulnerabilidades: 2.300 fallos reportados en 392 proyectos de código abierto, con datos actualizados a 26 de agosto de 2026. El trabajo arrancó en febrero de este año con Claude Mythos Preview y otros modelos de la casa, y el panel no se limita al titular: expone el proceso completo, incluida la parte que no luce.
Porque la cifra que de verdad cuenta la historia no es 2.300. Es otra, y está más abajo en el embudo.
26.153 hallazgos, 2.300 reportes, 421 parches
El recorrido completo de un fallo, tal como lo publica el panel, es este:
- 26.153 hallazgos candidatos identificados por los modelos.
- 5.008 revisados en el triaje inicial por firmas de seguridad externas.
- 4.576 confirmados como válidos, una tasa de aciertos del 91,4%.
- 2.300 reportados a los mantenedores de los proyectos.
- 1.815 reconocidos por esos mantenedores.
- 421 parcheados aguas arriba.
De veintiséis mil a cuatrocientos veintiuno. Ese estrechamiento es el dato más honesto del panel y también el más incómodo: encontrar vulnerabilidades ha dejado de ser el problema caro. Lo caro ahora es validarlas, comunicarlas y, sobre todo, que alguien con permiso de escritura en un repositorio saque un rato para arreglarlas. Menos de uno de cada cinco fallos reportados ha terminado en un parche.
Del esfuerzo se han derivado 462 identificadores de aviso: 177 registros CVE y 285 avisos de seguridad de GitHub. Y hay una cifra que conviene retener por lo que implica: solo 5.008 de los 26.153 hallazgos han pasado por triaje. Queda una cola enorme sin revisar.
Detectar el fallo ya es barato. Arreglarlo sigue dependiendo de que un mantenedor voluntario tenga la tarde libre.
Una inyección SQL de 9.1 en Ghost, y fallos en OpenSSL
No se trata de hallazgos menores en librerías que no usa nadie. Entre lo divulgado hay una inyección SQL en Ghost con una puntuación CVSS de 9,1, un salto de autenticación en Rocket.Chat, vulnerabilidades de uso después de liberar memoria en el kernel de Linux, desbordamientos de búfer críticos en FreeRDP y OpenSSL, y saltos de validación de certificados en wolfSSL.
Esa lista merece leerse dos veces si publicas sitios web. Ghost es un gestor de contenidos que compite directamente con WordPress y que muchos freelances despliegan para clientes de publicación; una inyección SQL de 9,1 en un CMS es exactamente el tipo de fallo que se convierte en una base de datos comprometida sin que nadie note nada durante semanas. OpenSSL, por su parte, está debajo de prácticamente cualquier conexión cifrada que hagan tus servidores, lo sepas o no.
Seis firmas externas revisando lo que encuentra la máquina
El diseño del programa es la parte más interesante desde el punto de vista metodológico. Anthropic colabora con seis firmas externas de investigación en seguridad que reproducen cada problema, evalúan su gravedad y preparan el informe para el mantenedor. Solo se salta ese paso cuando el propio proyecto pide recibir los hallazgos sin triar.
Es un reconocimiento implícito y sano: un modelo que encuentra un fallo no basta para molestar a un mantenedor voluntario. Cualquiera que mantenga un proyecto abierto conoce la plaga de los informes automáticos sin verificar, que consumen horas y no aportan nada. Que haya humanos entre la detección y el correo evita convertir el programa en una máquina de generar ruido.
El panel publica además hasta qué punto coincide la evaluación de gravedad del modelo con la de las firmas externas: 85,2% de coincidencia exacta y 97,1% dentro de una banda de diferencia. Es un dato poco habitual y bastante valioso, porque mide algo distinto de si el fallo existe: mide si la máquina acierta al juzgar cuánto importa. La divulgación se rige por ventanas escalonadas, en las que primero solo se publica un compromiso criptográfico, después el estado y la gravedad una vez avisado el mantenedor, y finalmente los detalles completos.
⚠️ Lo que esto significa para tus proyectos: si tienes instalaciones de Ghost, servicios apoyados en FreeRDP o servidores que llevan meses sin actualizar OpenSSL, este es el momento de repasar versiones. Un fallo divulgado es un fallo público: la ventana en la que solo lo conocían quienes lo encontraron se cierra al publicarse.
Revisa tus dependencias antes que el aviso público
La conclusión práctica para un desarrollador o un freelance es doble y nada dramática. La primera parte es rutinaria: revisar dependencias y versiones de lo que tienes desplegado, empezando por los proyectos de la lista. El programa está acelerando el ritmo al que aparecen avisos públicos, y un aviso público es también un mapa para quien quiera aprovecharlo antes de que actualices.
La segunda es de fondo. Si un laboratorio puede generar veintiséis mil hallazgos en seis meses, la misma capacidad está al alcance de quien no tiene intención de avisar a nadie. Ese es justo el escenario que denunciaba esta semana el llamamiento firmado por más de un centenar de compañías sobre ataques ejecutados por agentes. El panel es la cara defensiva de esa misma capacidad, y su cuello de botella —421 parches de 2.300 avisos— indica dónde va a doler: no en detectar, sino en la velocidad a la que el ecosistema es capaz de arreglar lo que ya sabe que está roto.
