El Centro Nacional de Ciberseguridad de los Países Bajos (NCSC) pasó cinco días diciendo a las organizaciones que se preocuparan por un fallo que nunca existió. El 29 de julio, el NCSC publicó el aviso NCSC-2026-0268, que alertaba sobre CVE-2026-51302, una falla de corrupción de memoria en SQLite 3.41 que llegó a recibir una calificación de gravedad de hasta 10 sobre 10. El lunes, la agencia retiró el aviso con una sola línea añadida, en la que señalaba que el CVE había sido retractado y que la vulnerabilidad muy probablemente fue alucinada por un modelo de lenguaje de gran tamaño.

El desenlace está documentado por el equipo de investigación de seguridad de JFrog, que rastreó el CVE hasta una cuenta de GitHub llamada programmervuln que había publicado 55 avisos de vulnerabilidades en SQLite. La auditoría de JFrog determinó que 54 eran completamente inventados y que uno contenía un fallo real envuelto en metadatos de CVE sin verificar. Las invenciones no eran sutiles una vez que alguien miraba de verdad. Las funciones citadas en los avisos no existen en las versiones de SQLite mencionadas, los números de línea referenciados apuntan más allá del final de los archivos, las cargas de prueba de concepto no hicieron fallar nada al ejecutarse bajo AddressSanitizer, y ninguno de los CVE aparece en la propia página de vulnerabilidades de SQLite. El texto mismo activó las alertas de GPTZero, la herramienta de detección de contenido generado por IA.

Lo que importa es cuán lejos viajó la ficción antes de que alguien la comprobara. El formulario público de envío de CVE de MITRE no realiza una verificación de identidad real, por lo que la cuenta pudo obtener al menos seis identificadores CVE, cuatro de ellos calificados como críticos o altos, incluidos dos con puntuación de 9,8 y uno de 9,1. NIST redujo el análisis manual de los envíos tras un aumento del trabajo acumulado a comienzos de 2024, lo que eliminó la capa que en otro momento podría haber detectado esto. Desde ahí, las puntuaciones fluyeron automáticamente hacia las bases de datos que consumen los escáneres de vulnerabilidades, los verificadores de dependencias y los equipos nacionales de respuesta. En los Países Bajos, la cadena terminó en un aviso gubernamental que pedía a las organizaciones aplicar parches.

SQLite es el peor blanco posible para este tipo de contaminación porque figura entre las piezas de software más ampliamente desplegadas del mundo, integrada en navegadores, teléfonos, sistemas operativos e incontables aplicaciones. Una puntuación crítica en su contra garantiza atención. Los investigadores de JFrog expresaron el coste sin rodeos, al escribir que estos CVE de desechos generados por LLM pueden hacer que las organizaciones pierdan tiempo investigando y parcheando vulnerabilidades que en realidad no existen, además de contaminar las bases de datos de vulnerabilidades. Ese coste se pagó en horas reales, por los equipos de seguridad que clasificaron las alertas y por una agencia nacional que emitió una advertencia y luego tuvo que retirarla.

La retractación en sí es la parte sana de esta historia, y las comprobaciones que finalmente destaparon el engaño, leer el código fuente, ejecutar el exploit, consultar la propia página de seguridad del proveedor, son exactamente las que la cadena omitió en el camino de entrada. La asimetría es el problema que persiste. Un modelo de lenguaje puede producir un aviso convincente en segundos, mientras que refutar uno exigió a los investigadores horas de verificación práctica por cada afirmación. El sistema de CVE se construyó sobre el supuesto de que los informes de vulnerabilidades se presentan de buena fe, y ese supuesto ahora tiene que sobrevivir al contacto con herramientas capaces de fabricar a escala una ficción segura de sí misma y bien formateada.