Un repositorio GitHub recién creado ha publicado una serie de avisos sobre presuntas vulnerabilidades críticas en SQLite. NVD ha asignado puntuaciones CVSS de hasta 9.8, y el ADP de CISA ha confirmado la gravedad. Cuando los investigadores de JFrog fueron a verificar, las funciones citadas no existían en las versiones indicadas, los proof-of-concept no provocaban ningún crash, y los presuntos parches eran inexistentes. Los avisos, procesados por un detector de contenido generado por IA, resultan producidos por un modelo de lenguaje.

Por qué te afecta. Los sistemas automáticos que clasifican vulnerabilidades han procesado estos falsos como si fueran reales. Si tu pipeline CI/CD incluye controles automáticos sobre las CVE de dependencias, es posible que hayas recibido alarmas sobre bugs inexistentes. Las infraestructuras críticas de seguridad ingieren contenido sin verificarlo, y ese contenido ahora puede ser generado por un LLM a costo casi cero.

Esto concierne a quienes usan agentes de IA para automatizar análisis de seguridad. La misma facilidad con la que un modelo escribe un aviso creíble a primera lectura es aquella con la que produce cualquier output plausible pero incorrecto. Un paso de verificación, aunque sea rápido, cuesta menos que una falsa alarma que dispara un plan de respuesta a un incidente inexistente.

En detalle

El repositorio programmervuln/cveadvisory- publicó a principios de agosto una veintena de avisos sobre vulnerabilidades en SQLite, más otros 50 reportes que JFrog considera igualmente generados por un LLM. La base de datos nacional de vulnerabilidades (NVD) registró seis de estos CVE con puntuaciones altas: dos a 9.8 (críticas), uno a 9.1, tres entre 7.5 y 8.8. El Automated Decision Plugin (ADP) de CISA validó las evaluaciones de gravedad.

JFrog siguió un protocolo riguroso para verificar cada reporte: clonación del repositorio oficial de SQLite, checkout de las versiones citadas (3.41.0, 3.51.2, 3.51.3), compilación en contenedores aislados, y testing de los proof-of-concept bajo AddressSanitizer para detectar violaciones de memoria.

Los resultados son inequívocos. La CVE-2026-51302 (9.8 crítica) cita la función exprComputeOperands() como origen de un use-after-free, pero esa función no existía en SQLite 3.41: fue introducida en 2025. La función sqlite3ReleaseTempReg() mencionada como causa del dangling pointer no asigna memoria heap: recicla índices de registro en un array, haciendo un UAF imposible por construcción.

La CVE-2026-51303 (9.8 crítica) describe un fix en la versión 3.51.3 que simplemente no existe. El diff entre 3.51.2 y 3.51.3 no muestra ninguna modificación a src/expr.c. El PoC asociado es SQL inválido y es rechazado por el parser antes de llegar a la lógica de ejecución.

La CVE-2026-51300 (9.1 crítica) cita números de línea específicos de expr.c que corresponden a un comentario y a una llamada de asignación, sin relación alguna con la lógica de eliminación descrita. El PoC, ejecutado como query válida, devuelve el output esperado sin memory leak.

Dos señales confirman el origen generativo. JFrog pasó los avisos a GPTZero, que los clasifica como contenido de IA. Y combinando todos los avisos en un único archivo, los detectores de contenido generado activan alertas inmediatas. El repositorio parece ser un experimento, o un ataque coordinado, donde alguien usa un LLM para producir avisos técnicamente plausibles a lectura superficial y los envía a los sistemas de seguimiento.

Qué cambia. La pipeline de confianza de vulnerabilidades funciona así: alguien publica un aviso, NVD lo registra, CISA lo evalúa, y las herramientas de escaneo de dependencias lo propagan a los desarrolladores. Hasta ahora el cuello de botella era la cantidad de avisos humanos. Con un LLM, el cuello de botella desaparece: puedes generar cientos de CVE creíbles a primera lectura en una tarde.

Red Hat inicialmente asignó a uno de estos CVE una puntuación de 10.0, luego la bajó a 7.6. Incluso equipos de triage profesionales, frente a un aviso bien construido, tienen dificultad para distinguir lo real de lo falso sin profundizar en el código.

Qué queda pendiente. No sabemos quién está detrás del repositorio, ni si el objetivo era probar los sistemas, crear ruido para cubrir algo más, o demostrar que se puede hacer. JFrog analizó seis CVE en detalle: los otros 50+ reportes del mismo repo quedan por verificar uno a uno. Y no sabemos cuántas herramientas automáticas de seguridad ya han alertado desarrolladores sobre estos CVE falsos, ni cuántos equipos han desplazado recursos para responder a amenazas inexistentes.