CISA enriqueció con metadatos un reporte de vulnerabilidad que no existía

Un usuario publicó 55 reportes de seguridad en GitHub en pocos días. JFrog verificó que 54 eran inventados por IA. Uno de ellos llegó a la base de datos oficial del gobierno de EE.UU. con puntuación perfecta.

CISA enriqueció con metadatos un reporte de vulnerabilidad que no existía

Foto: FlyD

Poco después de que un usuario anónimo publicara 55 reportes de vulnerabilidad en GitHub en cuestión de días, la firma de seguridad JFrog decidió someterlos a verificación. El resultado fue revelador: 54 de ellos eran completamente ficticios, generados por inteligencia artificial. La historia, que combina credibilidad institucional con fabricación automatizada, expone una falla crítica en los cimientos mismos de la ciberseguridad global.

La investigación de JFrog, publicada el 30 de julio, se centró inicialmente en seis reportes que señalaban supuestas vulnerabilidades críticas en SQLite, el motor de base de datos más utilizado en el mundo, presente en prácticamente todos los teléfonos inteligentes y navegadores. Según el análisis, los reportes inventaban funciones inexistentes dentro de las versiones de software mencionadas, citaban números de línea que superaban el final del archivo y adjuntaban código de prueba que, al ejecutarse, no producía ningún fallo.

Una de esas falsas alertas sobre SQLite llegó a recibir una puntuación de 10.0 en el sistema CVSS por parte de Red Hat, aunque luego fue corregida a 7.6. La función que supuestamente contenía el error no fue añadida al código de SQLite hasta 2025, un año después de la versión que se indicaba como afectada.

Patrocinado Advertisement

El problema no terminó en GitHub. Estos reportes falsos alcanzaron la National Vulnerability Database (NVD), el registro oficial del gobierno estadounidense que alimenta a escáneres de seguridad y sistemas de defensa en todo el mundo. Allí, la NVD los clasificó como críticos y un equipo de CISA los enriqueció con metadatos. El sistema funciona sobre la base de la confianza: cualquier persona puede solicitar un CVE (Identificador Común de Vulnerabilidad y Exposición) a través de un formulario público de MITRE, y los organismos encargados de asignarlos no verifican si el reporte es reproducible. Como señaló el ingeniero de Oracle Alan Coopersmith, el CNA (Autoridad de Numeración CVE) a menudo no está en condiciones de verificar el informe por sí mismo.

NIST solía ser el filtro final. Sus expertos revisaban cada registro manualmente. Pero la avalancha de presentaciones los obligó a pausar el análisis profundo a principios de 2024. Para finales de 2025, la acumulación de reportes sin procesar superaba los 27.000. Una auditoría federal determinó que la agencia había desperdiciado dinero al no depurar la lista. Hoy, ningún paso del proceso exige que alguien reproduzca el fallo antes de que este sea considerado oficial.

El verdadero peligro, según JFrog, está en lo que ocurre después. Cada vez más equipos de seguridad utilizan agentes de IA para analizar y corregir código automáticamente a partir de los CVE publicados. Si a uno de estos agentes se le entrega un reporte falso, comenzará a buscar una función vulnerable que nunca existió y modificará código funcional para parchear un problema inexistente. El ciclo ya casi no involucra a un humano: una IA genera un reporte creíble, un proceso con poco personal lo aprueba, y otra IA intenta corregirlo.

Para América Latina, donde los equipos de ciberseguridad suelen ser más reducidos y los recursos de verificación son limitados, el riesgo es mayor. Muchas empresas dependen directamente de fuentes como la NVD para priorizar parches. Un CVE falso con puntuación crítica puede desviar a un equipo completo de seguridad hacia una investigación inútil durante días, mientras descuida amenazas reales. El costo de oportunidad en startups y pymes, donde cada hora de trabajo cuenta, puede ser devastador.

JFrog verificó los 55 reportes y encontró que solo uno contenía un error real, aunque envuelto en metadatos falsos. El resto inventaba agujeros en SQLite, la biblioteca de imágenes libraw y un decodificador de audio para Arduino. El costo de generar engaños creíbles es hoy cercano a cero. El de verificarlos sigue siendo el mismo de siempre: leer el código fuente, compilar la versión, ejecutar la prueba.

Generar una vulnerabilidad falsa con IA es barato y rápido. Verificarla sigue siendo caro y lento. Y esa asimetría, cuando las máquinas pueden mentir a escala, es la nueva frontera del riesgo operativo. La pregunta que debería hacerse cualquier ejecutivo de tecnología en la región es: si su sistema de defensa se alimenta de datos que nadie verifica, ¿cuántas decisiones está tomando basándose en ficción?

Fuentes

  1. ¿Producción en masa de vulnerabilidades inexistentes con IA? Falso CVE de «SQLite» descubierto; empresa estadounidense lo verifica
  2. Alguien publicó 55 vulnerabilidades en días. 54 fueron inventadas por IA. Una aún obtuvo una puntuación perfecta de 10.
  3. IA en la detección de vulnerabilidades: una llamada a la supervisión y ...
Ariel Acosta

Escrito por

Ariel Acosta

Experto en seguridad de información

Ingeniero en sistemas y gestor de servicios de TI con más de 10 años de experiencia en diseño, implementación y administración de infraestructura de red, seguridad y procesos tecnológicos. Ha desarrollado una carrera orientada a sostener operaciones críticas, optimizar entornos corporativos y traducir necesidades técnicas en soluciones funcionales para organizaciones que dependen de plataformas estables, seguras y alineadas con el negocio, con foco en eficiencia y control.