El 27 de julio se publicaron seis vulnerabilidades de SQLite con puntuaciones de entre 9,8 y 7,5, de críticas para arriba. SQLite está incrustado en casi cualquier producto con software: móviles, navegadores, coches, cajas registradoras. Media industria puso el reloj en marcha.
Ninguna de las seis existía. La web oficial de SQLite las lista ahora bajo una frase seca: no es un fallo suyo, son irreproducibles y parecen alucinaciones de una IA. El NVD ha rechazado los seis. Pero a 4 de agosto GitHub seguía sirviendo uno como crítico, con un 9,8 y sin marca de retirada.
Qué se publicó exactamente
Los seis salieron con MITRE como autoridad asignadora. El investigador Afek Berger los desmontó uno a uno en un análisis de JFrog: uno citaba una función que no existía en la versión afectada, otro señalaba las líneas 3555 y 3575 de un archivo que solo tiene 2.706, y la prueba de concepto de un tercero se ejecutaba sin incidentes y devolvía resultados ordenados.
No eran seis avisos sueltos. Un repositorio recién creado había publicado 55 en cuatro días: 54 estaban completamente fabricados y solo uno contenía un fallo real. D. Richard Hipp, creador de SQLite, escribió en el foro del proyecto que había muestreado varios y no había encontrado ninguno válido.
Por qué el sistema se lo tragó
El proceso no exige que nadie reproduzca el fallo. Alan Coopersmith, ingeniero de Oracle Solaris, lo resumió así: MITRE y la mayoría de autoridades que asignan CVE sobre código ajeno funcionan por confianza y dan por buena la información que reciben. Berger lo plantea como un problema de costes: generar un aviso verosímil ya no cuesta casi nada, y verificarlo cuesta lo mismo que siempre.
El colchón que amortiguaba esto tampoco está. El NVD pasó el 15 de abril a un triaje por riesgo y solo enriquece los registros que entran en el catálogo de CISA. En el primer semestre de 2026 se publicaron 35.364 CVE, casi un 50% más que un año antes, y solo 85 llegaron a ese catálogo. El mismo patrón que ya vimos con el código generado con IA: mucho volumen, poca verificación.
Qué significa para las empresas españolas
Aquí está la parte con fecha. Desde el 11 de septiembre de 2026, el Cyber Resilience Act obliga a los fabricantes de productos con elementos digitales que venden en la UE a notificar las vulnerabilidades explotadas activamente a ENISA y a su CSIRT nacional, que en España gestiona el INCIBE: aviso en 24 horas y notificación completa a las 72.
Entran ahí muchas más pymes de las que se creen: cualquiera que venda hardware conectado o embarque software en su producto. Desde septiembre tendrás un reloj legal atado a un feed que acaba de tragarse 54 avisos inventados en cuatro días, apenas un mes después de las obligaciones de transparencia del AI Act.
Cómo filtrar un aviso en cinco minutos
Antes de movilizar al equipo, cuatro comprobaciones. Mira si el fabricante ha corroborado el fallo en su web de seguridad, que es lo que zanjó este caso. Busca en las referencias un hash de commit o una pull request: un fallo real casi siempre lleva un parche detrás.
Comprueba si el CVE figura en el catálogo de CISA. Y ten presente que, desde abril, que un registro esté en el NVD ya no significa que alguien lo haya validado.
El fallo no fue del modelo
Conviene no quedarse con la conclusión fácil. Los avisos parecen generados por IA, y tanto SQLite como JFrog lo dicen con esa cautela, pero lo que falló fue un proceso que nunca pidió una prueba. Daniel Stenberg cerró en enero el programa de recompensas de curl por este motivo y lo reabrió en marzo; en abril el ruido ya no era problema.
La lectura útil para quien automatiza: si has puesto un agente a triar vulnerabilidades o a parchear solo, la entrada puede venir fabricada. Automatizar sigue compensando; hacerlo sin un paso de verificación es lo que sale caro, y es la parte de la estrategia de IA que suele llegar tarde.
