Un lote de 54 CVEs falsos, generados con IA, logró colarse en la base de datos nacional de vulnerabilidades de EE. UU. y en escáneres comerciales. JFrog demostró que seis supuestas fallas en SQLite eran completamente inventadas, revelando un problema sistémico en la cadena de avisos de seguridad. Mientras NIST lidia con un retraso enorme, la falta de verificación automática convierte a la IA en una amenaza para la ciberseguridad.
***
- JFrog detectó seis CVEs de SQLite falsos con puntajes CVSS de 9.8 a 7.5, incluyendo uno que Red Hat marcó inicialmente con 10.0.
- Los 54 informes del repositorio de GitHub fueron rechazados por MITRE, pero ya habían contaminado bases de datos y escáneres.
- El retraso de NVD supera los 27.000 CVEs sin procesar, y la IA generativa facilita producir avisos engañosos a bajo costo.
El fraude de las vulnerabilidades inventadas
La semana pasada, un lote de seis vulnerabilidades supuestamente críticas en SQLite apareció en la Base de Datos Nacional de Vulnerabilidades de EE. UU. (NVD) con enriquecimiento proporcionado por CISA. Sin embargo, investigadores de la compañía de seguridad JFrog descubrieron que eran completamente falsas, generadas por inteligencia artificial.
Las seis CVEs llevaban puntuaciones CVSS que iban desde 9.8 hasta 7.5, catalogadas como altas o críticas. Una de ellas, descrita como un error de uso después de liberar (UAF), recibió inicialmente una puntuación perfecta de 10.0 por parte de Red Hat antes de ser reducida.
Al analizar el código, JFrog encontró que la supuesta vulnerabilidad dependía de una función inexistente en la versión afectada de SQLite. Otro informe citaba líneas de código que no tenían relación con el supuesto defecto, y la prueba de concepto ejecutó una consulta válida sin fugas de memoria.
El origen de estos informes era un repositorio nuevo y oscuro en GitHub que también contenía otras 49 CVEs para la biblioteca de procesamiento de imágenes RAW libraw y la biblioteca de decodificación de audio ESP32-audioI2S. Según JFrog, todos eran igualmente falsos, salvo uno que contenía un error real envuelto en metadatos no verificados.
Un mensaje en la lista OSS-Security de Openwall indicó que MITRE había rechazado la totalidad del conjunto de 54 vulnerabilidades vaporosas. No obstante, el daño ya estaba hecho: esos avisos lograron ingresar a bases de datos usadas por escáneres empresariales.
El descubrimiento de JFrog y la reacción de la industria
JFrog publicó su análisis la semana pasada, señalando que al pasar los avisos por un verificador de IA se sugería que eran probablemente generados por IA. Las pruebas posteriores confirmaron que no describían ninguna vulnerabilidad reproducible.
La empresa de seguridad de la cadena de suministro informó sus hallazgos al equipo de Aviso de Seguridad de GitHub, a Red Hat y a la NVD. Todos, excepto GitHub, marcaron o eliminaron los CVEs, según afirmó JFrog. El repositorio de GitHub que contiene los informes falsos aún estaba activo al momento de la publicación.
Alan Coopersmith, ingeniero de Oracle Solaris, comentó en OSS-Security que MITRE y la mayoría de otros CNAs operan en un sistema de honor. “El CNA a menudo no está en posición de poder verificar el informe ellos mismos”, señaló. Esta falta de verificación es la raíz del problema.
El investigador de seguridad de JFrog, Afek Berger, expresó que la IA generativa ha reducido el esfuerzo para producir un aviso plausible a casi cero, mientras que verificar uno requiere revisar código, crear la versión afectada y reproducir la prueba de concepto. “Esa asimetría significa que incluso los defensores bien financiados no pueden validar manualmente cada informe entrante”, dijo.
El incidente demuestra un problema sistémico con la ingestión automatizada de vulnerabilidades, ya que ningún paso del sistema actual exige una prueba de concepto o reproducción del error. Esto permite que avisos falsos con apariencia plausible se deslicen fácilmente a los escáneres.
El colapso de la NVD y el retraso acumulado
La NIST, que gestiona la Base de Datos Nacional de Vulnerabilidades, solía proporcionar un respaldo confiable mediante revisión y enriquecimiento manual de cada CVE. Ese proceso se desaceleró drásticamente en 2024 tras un aumento en presentaciones y desafíos operativos.
A finales de 2024, el retraso había crecido a más de 17.000 CVEs no procesados, a pesar del plan de NIST para despejarlo antes del cierre del año fiscal. Sin embargo, continuó creciendo hasta superar los 27.000 para finales de 2025, según un informe del Inspector General del Departamento de Comercio publicado en mayo de 2026.
El informe concluyó que NIST malgastó el dinero asignado para arreglar el problema debido a una “falta de planificación estratégica y acción decisiva”. La pila de problemas no resueltos no para de crecer, lo que deja a los profesionales de seguridad sin un punto de control obligatorio para validar vulnerabilidades reclamadas.
La empresa JFrog destacó que en lugar de confiar en bases de datos contaminadas, los defensores deberían adoptar comprobaciones adicionales antes de actuar sobre un CVE recién publicado. Estas incluyen verificar si el proveedor ha corroborado el problema y si existen referencias de código válidas.
La situación refuerza la necesidad de que las entidades asignadoras de CVE implementen procesos de verificación más estrictos, incluso aunque esto implique una mayor carga de trabajo. Sin cambios, la contaminación del ecosistema de seguridad seguirá siendo un riesgo creciente.
Recomendaciones para profesionales de seguridad
JFrog ofreció varias recomendaciones prácticas para distinguir un CVE legítimo de uno falso. Primero, si el proveedor del producto no ha corroborado el problema, como en el caso de SQLite que no lista esos informes, probablemente sea falso.
También sugirió revisar que el informe contenga un hash de confirmación o una solicitud de extracción en los campos de referencia. La ausencia de estos metadatos, junto con definiciones CPE faltantes, son indicativos de desechos de IA.
Además, si las referencias al código no coinciden con funciones reales o apuntan a partes que no implican el supuesto problema, es una clara señal de alucinación de IA. Los profesionales deben verificar la existencia de una prueba de concepto funcional.
El investigador Afek Berger señaló que el esfuerzo y costo de generar un aviso falso es casi nulo, mientras que verificar uno requiere tiempo y recursos significativos. Esto crea una ventaja para los atacantes o para quienes buscan inflar su experiencia con informes falsos.
La recomendación general es no confiar automáticamente en los CVEs que aparecen en bases de datos, especialmente si provienen de repositorios poco conocidos. La verificación manual con código fuente y pruebas de concepto sigue siendo indispensable en la era de la IA.
El futuro de la seguridad ante la IA generativa
Este incidente con los CVEs falsos de SQLite y libraw no es un caso aislado, sino una advertencia de lo que viene. JFrog espera ver más casos de este tipo a medida que la IA generativa se vuelve más accesible.
La contaminación de las bases de datos de vulnerabilidades no solo hace perder tiempo a los profesionales, sino que también desvía recursos de la persecución de problemas reales. Los escáneres empresariales que ingieren estos datos pueden producir falsos positivos, causando caos innecesario.
La industria necesita desarrollar métodos automatizados para detectar y filtrar vulnerabilidades falsas, como la verificación del código fuente referenciado o el análisis de metadatos inconsistentes. La colaboración entre proveedores, CNAs y NIST es crucial para restaurar la confianza en el sistema.
Mientras tanto, los equipos de seguridad deben adoptar un enfoque cauteloso, corroborando cada CVE crítico antes de tomar acciones. La educación sobre cómo identificar avisos generados por IA se vuelve esencial para todos los profesionales de TI.
En última instancia, la asimetría señalada por Berger obliga a repensar el modelo de honor actual. Sin una verificación obligatoria, la integridad de la cadena de suministro de software seguirá en juego ante el poder disruptivo de la IA.
ADVERTENCIA: DiarioBitcoin ofrece contenido informativo y educativo sobre diversos temas, incluyendo criptomonedas, IA, tecnología y regulaciones. No brindamos asesoramiento financiero. Las inversiones en criptoactivos son de alto riesgo y pueden no ser adecuadas para todos. Investigue, consulte a un experto y verifique la legislación aplicable antes de invertir. Podría perder todo su capital.
Suscríbete a nuestro boletín
Artículos Relacionados
Empresas
La demostración es solo el 1% del trabajo: las 7 lecciones de Waymo para construir IA física
Criptomonedas
Agente de IA ataca a otro agente en el primer exploit de cadena de suministro con Google ADK
China
Hugging Face CEO afirma que China domina la IA tras hackeo de OpenAI
Estados Unidos