JFrog Security Research investigó avisos de vulnerabilidad de SQLite publicados por una cuenta de GitHub recién creada (programmervuln/cveadvisory-). La NVD los marcó como críticos y el ADP de CISA estuvo de acuerdo, pero la verificación desarmó las afirmaciones: el código citado no existía en las versiones nombradas, los PoC no provocaron ningún fallo, ninguno de los CVE figura en la página oficial de advisories de SQLite y las pruebas con GPTZero indicaron textos generados por IA.

Se analizaron seis CVE en detalle. CVE-2026-51302 (9,8 crítico) alega un use-after-free vía exprComputeOperands(), función inexistente en SQLite 3.41.0 y añadida recién a mediados de 2025; sqlite3ReleaseTempReg() solo recicla índices de registros, por lo que un UAF es imposible por diseño. CVE-2026-51303 (9,8) invoca un parche en 3.51.3, pero el diff entre 3.51.2 y 3.51.3 no muestra cambios en src/expr.c; su PoC es SQL inválido. CVE-2026-51300 (9,1) cita líneas de expr.c que corresponden a un comentario y a una asignación de memoria sin relación. CVE-2026-51297 (8,8) menciona jsonBlobEdit(), inexistente en 3.41.0. CVE-2026-51296 (7,5) cita las líneas 3555/3575 de json.c, un archivo de solo 2706 líneas. CVE-2026-51304 (7,5) usa una firma de función inexistente, mientras el código real anula el puntero inmediatamente tras eliminarlo. Todos los PoC se ejecutaron en contenedores Docker con AddressSanitizer contra compilaciones oficiales de las versiones 3.41.0, 3.51.2 y 3.51.3, sin ningún error de memoria. Red Hat puntuó inicialmente CVE-2026-51302 con 10,0 crítico y luego lo rebajó a 7,6 alto.

JFrog atribuye el incidente a una cadena rota: el formulario de MITRE no exige verificación de identidad y, desde que el NIST pausó el análisis profundo de la NVD en febrero de 2024, avisos falsos pero plausibles pueden llegar a GHSA, bases de datos posteriores y escáneres empresariales sin reproducir ningún bug. La auditoría de 55 avisos de la misma cuenta halló 54 completamente fabricados y solo uno con un bug real envuelto en metadatos CVE no verificados.

Señales de alarma según los investigadores: ausencia de mención en las páginas oficiales de seguridad de los mantenedores, falta de commits o PR enlazados, metadatos CPE contradictorios y referencias a funciones o líneas inexistentes. Los CVE críticos falsos desperdician esfuerzo de triaje y parcheo — y los agentes de IA usados en remediación automatizada podrían intentar parchear código inexistente. Los hallazgos fueron reportados a GHSA, Red Hat y la NVD.