CVEs fantasmas: cuando una IA fabricó 54 vulnerabilidades falsas de SQLite y los «expertos» las aprobaron
Hace unos días me encontré con una noticia que me dejó helado. Un repositorio nuevo en GitHub, creado por una cuenta sin historial, publicó más de 50 CVEs para SQLite. NVD las calificó como críticas. CISA, a través de su ADP, las respaldó. El problema? Todas eran inventadas por una IA.
Los investigadores de JFrog Security se pusieron a revisar el código y lo que encontraron es de no creer. Funciones que supuestamente tenían bugs ni siquiera existían en las versiones reportadas. Líneas de código citadas como vulnerables estaban más allá del final del archivo. Los PoC, esos exploits que deberían demostrar el fallo, simplemente no funcionaban: devolvían errores de SQL malformado o ejecutaban queries normales sin crash.
De 55 advisories publicados por la misma cuenta, 54 eran puro slop de LLM. La evidencia? GPTZero detectó que los textos eran generados por IA. Pero lo peor no es que una IA haya inventado bugs. Lo peor es que todo el pipeline de seguridad se los tragó sin masticar.
NVD les puso CVSS 9.8 Critical. Red Hat inicialmente les asignó 10.0. Empresas con scanners automáticos ya estaban generando tickets para parchear algo que nunca existió. Imagínate perder horas de la pega — o peor, introducir cambios innecesarios en producción — porque una IA alucinó una vulnerabilidad y nadie en la cadena de validación se tomó el tiempo de compilar el código y correr el PoC.
Para mí esto es una señal de alerta brutal. La industria de ciberseguridad está obsesionada con la velocidad: más CVEs, más scanners, más automatización. Pero sin un humano que revise si la función citada existe, si la línea de código está dentro del archivo, si el PoC realmente crashea, estás construyendo un castillo de naipes con datos basura.
Y esto va a empeorar. Si los agentes de IA empiezan a automatizar el triage y la remediación, un CVE fantasmas no solo genera ruido: puede hacer que una IA agente busque funciones inexistentes, genere parches para bugs que nunca existieron, o recomiende cambios que rompan código funcionando. No estamos hablando de un error de ChatGPT escribiendo un email. Estamos hablando de la integridad de toda la cadena de suministro de seguridad.
Mi takeaway? No confíes ciegamente en un CVE solo porque tiene número oficial y score crítico. Revisa si el vendor lo corrobora en su página de advisories. Busca el commit hash o el PR. Y sobre todo, si tienes un PoC, ejecútalo en un entorno aislado antes de mandar el alerta a todo el equipo de seguridad. Porque hoy en día, no solo los atacantes pueden mentirte. También los modelos de lenguaje.
Fuente de inspiración: SQLite Critical CVEs or LLM Slop?
