CVE falsos, informes generados por IA y la necesidad de verificarlos

Cada vez cuesta menos crear informes de vulnerabilidades convincentes, lo que aumenta las consecuencias para quienes mantienen software y para los equipos de seguridad. En julio de 2026 se publicaron seis vulnerabilidades y exposiciones comunes (CVE) relacionadas con SQLite, y dos de ellas recibieron una puntuación de gravedad de 9.8. Los informes parecían legítimos: describían errores de seguridad de memoria e incluían explicaciones técnicas y código de prueba de concepto.

Sin embargo, los investigadores de JFrog descubrieron que algunas de las funciones mencionadas en esos informes no existían en las versiones afectadas. Además, ninguna de las pruebas de concepto (PoC) reprodujo las vulnerabilidades alegadas. Actualmente, la página de CVE de SQLite indica que estos seis informes no corresponden a errores; posteriormente, se rechazaron los registros de CVE.

El problema va más allá de SQLite. Daniel Stenberg, responsable del mantenimiento de curl, estimó el año pasado que alrededor del 20 % de los informes de seguridad recibidos eran basura generada por IA. La Autoridad de Numeración de CVE (CNA) de GitHub recibió casi 4.000 solicitudes de CVE en mayo de 2026; eso supone un aumento del volumen de aproximadamente 10 veces con respecto al año anterior. GitHub no atribuyó este aumento a la IA ni señaló una disminución en la calidad de las solicitudes, pero el enorme crecimiento del volumen pone de relieve la sobrecarga del proceso de divulgación de vulnerabilidades.

La IA facilita la elaboración de afirmaciones detalladas sobre vulnerabilidades, pero determinar si son legítimas lleva tiempo. Además, una vez que un CVE aparece en fuentes de información de seguridad y bases de datos públicas, corregir el registro original no significa automáticamente que se corrijan todas sus copias. Esto hace cada vez más necesario distinguir entre una vulnerabilidad notificada y otra verificada técnicamente.

¿Qué es un CVE «falso»?

Se suele utilizar el término «CVE falso» para referirse a un CVE que probablemente se notificó por error. Pero «falso» no significa que haya intención de engañar. Puede deberse a un análisis estático que pasa por alto una comprobación de validación o interpreta erróneamente que un atacante controla la entrada. Un informe puede describir una función real y, aun así, alegar una vía de ataque no válida. Se puede asignar un identificador (ID de CVE) y luego descartarlo si la condición notificada no constituía, de hecho, una vulnerabilidad. Esto es distinto de un informe deliberadamente ficticio.

Una discrepancia tampoco convierte un CVE en falso. Un proveedor puede cuestionar las conclusiones de un investigador sobre la explotabilidad, los límites de la amenaza o si una función estaba destinada a procesar entradas no confiables. Pero una discrepancia no demuestra que el investigador se haya equivocado. Y que se rechace un CVE no significa necesariamente que se haya inventado: puede rechazarse por ser un duplicado o por motivos administrativos. Aunque un identificador de CVE no constituye una verificación técnica independiente, el sector debe tomarse en serio los informes legítimos.

Por qué los CVE falsos son un problema

Uno de los problemas que estamos viendo es que algunas personas utilizan la IA para generar informes de vulnerabilidades sin validar debidamente los hallazgos. Estos informes pueden incluir explicaciones técnicas detalladas, referencias al código e incluso pruebas de concepto, lo que puede hacer que parezcan legítimos. Sin embargo, como vimos con los CVE de SQLite, algunas de las funciones mencionadas ni siquiera existían en las versiones afectadas.

GitHub informó de un aumento significativo de las notificaciones de vulnerabilidades en 2026, aunque no atribuyó ese aumento a la IA ni comunicó un descenso en la calidad de las solicitudes. La preocupación es que, a medida que aumenta el número de informes, también crece el trabajo necesario para investigarlos, independientemente de que los hallazgos sean legítimos o no.

Quienes han clasificado informes de vulnerabilidades conocen bien la dificultad práctica. Un modelo de IA puede detectar una llamada a una API sospechosa, esbozar un escenario de explotación y generar rápidamente un informe de aspecto profesional. Para determinar si ese escenario es viable, puede ser necesario comprobar la versión exacta, rastrear el flujo de control, averiguar cómo llegan los datos a la función, crear un entorno de pruebas y ejecutar el supuesto exploit. El proceso es el mismo tanto si el informe es correcto como si no, y puede resultar costoso.

Los CVE falsos también pueden causar daños a la reputación. El anuncio de una vulnerabilidad puede propagarse rápidamente por fuentes de información para escáneres, bases de datos de seguridad y resultados de búsqueda. Sin embargo, la corrección posterior quizá no llegue tan lejos. Incluso después de que se haya cuestionado o rechazado un informe, los proveedores pueden verse obligados a defenderse ante clientes que vieron el informe original.

También existe el riesgo de que se pasen por alto vulnerabilidades reales o se retrase su investigación porque los equipos dedican tiempo a analizar informes incorrectos. Cuando quienes mantienen el software y los equipos de seguridad cuentan con recursos limitados, cada hora dedicada a descartar un falso positivo es una hora que podría haberse dedicado a investigar un problema de seguridad real.

Cómo responder con automatización

Muchos investigadores todavía recurren a la clasificación manual para hacer frente a la nueva avalancha de informes, pero este método no es sostenible. La automatización está demostrando ser de gran ayuda para verificar las afirmaciones sobre vulnerabilidades en relación con la versión y la configuración realmente afectadas. Estas son las cinco preguntas que conviene plantearse:

• ¿Son creíbles los requisitos previos para el ataque, incluidos la configuración y los permisos?
• ¿Existe la función supuestamente afectada en la versión vulnerable?
• ¿Puede un atacante llegar al código vulnerable? Determine si el código pertinente puede ejecutarse en las condiciones afectadas y si un atacante puede proporcionar datos de entrada que lleguen hasta él.
• ¿Pueden los evaluadores reproducir el comportamiento en una prueba controlada o con una prueba de concepto (PoC)?
• ¿El comportamiento observado presenta el impacto en la seguridad descrito en el aviso?

Las herramientas basadas en agentes pueden crear entornos de prueba, analizar rutas de código, generar pruebas de concepto (PoC) y registrar evidencias de ejecución para su revisión. No pueden resolver automáticamente todas las afirmaciones. Incluso cuando una vulnerabilidad es auténtica, una PoC puede fallar si el entorno está incompleto o el desencadenante no es el correcto. Los evaluadores pueden reproducir un fallo sin demostrar la explotabilidad alegada. Estas salvedades explican por qué el criterio humano sigue siendo crucial. Sin embargo, estas herramientas pueden ayudar a los equipos a acercarse a una respuesta reproducible antes de que un informe consuma más tiempo de los equipos de ingeniería, gestión de vulnerabilidades y soporte al cliente.

Cómo superar la saturación en el ecosistema de CVE

Ninguna política concisa resolverá por arte de magia el problema de las CVE falsas. Sin embargo, ayudaría exigir pruebas más sólidas al presentar informes y ofrecer información más clara sobre su reproducibilidad. También sería útil establecer un tratamiento más claro de los registros controvertidos y corregir con mayor rapidez los datos derivados. Se debería animar a los investigadores a validar sus hallazgos asistidos por IA antes de presentarlos.

Los equipos de seguridad y los proveedores deben centrarse en examinar las pruebas. Una puntuación crítica de CVE no indica si es posible acceder a una ruta vulnerable desde su entorno. Que una PoC falle no significa que todo esté bien. Además, recibir un identificador CVE no exime a los equipos de realizar el trabajo técnico necesario para comprender un problema.

La IA está mejorando la capacidad de descubrir vulnerabilidades y también está permitiendo crear afirmaciones que parecen sólidas, pero son incorrectas. En un mundo donde proliferan los informes, las organizaciones deben invertir en verificación. Esto implica crear pruebas, reproducir resultados, comprobar supuestos y facilitar la evaluación de las pruebas. Las pruebas de seguridad basadas en agentes podrían desempeñar un papel importante en este ámbito.