SQLite llegó a Hacker News después de que CVE críticos se desmoronaran bajo revisión

SQLite llegó a Hacker News después de que seis registros de vulnerabilidades recibieran calificaciones graves, incluidas tres puntuaciones críticas, pese a que las afirmaciones técnicas posteriormente no superaron una verificación básica.

Investigadores de JFrog informaron que los avisos hacían referencia a funciones inexistentes, números de línea imposibles, correcciones fabricadas y consultas de prueba de concepto que no provocaban los fallos alegados. El lote cuestionado incluía CVE-2026-51302, que recibió una puntuación crítica de 9,8 antes de que su afirmación subyacente se desmoronara.

El incidente es más grande que una sola presentación cuestionable. Expone un conflicto entre la publicación automatizada de vulnerabilidades y la revisión de seguridad basada en evidencia. Un registro de apariencia creíble puede entrar en bases de datos, escáneres y colas de tickets antes de que alguien reproduzca el supuesto fallo.

Ese conflicto importa porque los equipos de seguridad tratan un CVE, o identificador de Common Vulnerabilities and Exposures, como infraestructura compartida. Un número CVE no demuestra que exista una vulnerabilidad. Sin embargo, los inventarios de software y los sistemas de cumplimiento suelen tratar el número como un hecho operativo.

Este caso, por tanto, invierte la historia habitual de seguridad. El peligro aparente no era un fallo oculto de memoria en SQLite. Era una alerta de apariencia oficial que envió a los defensores a buscar código que nunca estuvo presente.

Lo que realmente afirmaban los registros CVE de SQLite

Los registros cuestionados describían graves fallos de seguridad de memoria, pero sus fundamentos técnicos no sobrevivieron a la inspección del código fuente ni a las pruebas.

El lote abarcaba seis supuestas vulnerabilidades de SQLite. Tres recibieron calificaciones CVSS críticas, mientras que las tres restantes fueron calificadas como altas. CVSS, o Common Vulnerability Scoring System, estima la gravedad técnica mediante factores como el acceso para el ataque y el impacto potencial.

CVE-2026-51302 recibió una puntuación crítica de 9,8. Su aviso alegaba una condición de uso después de liberación que involucraba a sqlite3ReleaseTempReg() y exprComputeOperands() en SQLite 3.41.0.

Un uso después de liberación ocurre cuando un software accede a memoria después de liberarla. Estos errores pueden causar bloqueos, filtrar datos o, en ocasiones, permitir la ejecución de código. Eso hace que la etiqueta resulte especialmente alarmante cuando aparece junto a una biblioteca de base de datos ampliamente integrada.

Sin embargo, JFrog encontró una contradicción directa. La función denominada exprComputeOperands() no existía en SQLite 3.41.0. Según los investigadores, entró en la base de código durante 2025, mucho después de la versión afectada citada por el aviso.

La otra función mencionada tampoco realizaba la desasignación de memoria alegada. Reciclaba índices de registros temporales para reutilizarlos más adelante. Ese comportamiento no respaldaba el mecanismo de uso después de liberación reportado.

JFrog compiló versiones oficiales de SQLite en contenedores aislados y ejecutó las consultas enviadas con AddressSanitizer. AddressSanitizer es una herramienta de compilador que detecta accesos inválidos a memoria durante la ejecución. La consulta de CVE-2026-51302 se completó sin producir el bloqueo alegado.

La investigación técnica encontró problemas comparables en los otros cinco registros de SQLite.

CVE-2026-51303 alegaba que ExprListDelete() dejaba referencias inversas peligrosas en estructuras padre. También afirmaba que SQLite 3.51.3 contenía una corrección relevante. JFrog no encontró una estructura de punteros que lo respaldara ni un cambio correspondiente en src/expr.c entre las versiones 3.51.2 y 3.51.3.

Su prueba de concepto no alcanzaba la lógica supuestamente vulnerable. La consulta enviada era SQL no válido y se detenía en el analizador sintáctico.

CVE-2026-51300 citaba dos líneas de expr.c como evidencia de otro problema de uso después de liberación. Una de las líneas citadas era un comentario, mientras que la otra era una llamada de asignación de memoria no relacionada con el puntero descrito.

Esa consulta se ejecutó correctamente y devolvió el resultado esperado. Los investigadores no reportaron ningún error de memoria ni fuga bajo su instrumentación de pruebas.

Dos registros relacionados con JSON presentaban inconsistencias igual de visibles. CVE-2026-51297 hacía referencia a jsonBlobEdit() en SQLite 3.41.0, aunque esa función llegó después con el trabajo de JSONB de SQLite. Su entrada enviada se detenía con un error de JSON malformado.

CVE-2026-51296 citaba las líneas 3555 y 3575 en una versión de json.c que solo contenía 2.706 líneas. JFrog localizó la implementación real de jsonRemoveFunc mucho antes y no reportó ningún fallo coincidente de gestión de memoria.

Por último, CVE-2026-51304 describía una llamada inválida de un solo argumento a sqlite3ExprListDelete(). La función real requiere un argumento de contexto de base de datos. El código de SQLite circundante también borraba el puntero relevante inmediatamente después de eliminarlo.

Ninguna de esas observaciones, por sí sola, establece cómo se produjeron los avisos. JFrog utilizó un detector de contenido de IA y describió el material como probablemente generado por un LLM, pero los detectores automatizados no son herramientas definitivas de atribución.

La evidencia más sólida está dentro de los propios avisos. Funciones ausentes, ubicaciones imposibles, parches inventados y pruebas ineficaces son defectos verificables independientemente de quién o qué escribió el texto.

Para el 4 de agosto, el registro de NVD de CVE-2026-51302 mostraba un estado rechazado. Su aviso de rechazo indicaba que una investigación posterior concluyó que la condición reportada no era un problema de seguridad.

Esa corrección importa. Sin embargo, el registro ya había adquirido una etiqueta crítica, visibilidad posterior y suficiente atención como para convertirse en una discusión en Hacker News.

Por qué Hacker News se centró en el fallo de validación

El atractivo para Hacker News surgió de una inversión inquietante: los metadatos estructurados de seguridad parecían más autoritativos que el código que supuestamente describían.

Un identificador CVE está diseñado para dar a los defensores un nombre común para una vulnerabilidad reportada. Permite que proveedores, investigadores, escáneres, clientes y sistemas gubernamentales hablen del mismo problema sin ambigüedad.

El identificador no pretende certificar la explotabilidad. Un CVE recién publicado puede contener afirmaciones a la espera de análisis más profundos, correcciones o revisión por parte del proveedor. Esa distinción resulta familiar para los especialistas en vulnerabilidades, pero es menos visible en los flujos de trabajo automatizados.

El incidente de SQLite demuestra lo que ocurre cuando las máquinas consumen el identificador como un veredicto. Un escáner puede hacer coincidir una versión de producto, heredar una puntuación de gravedad y generar un ticket de remediación sin comprobar si existe la función citada.

Una puntuación crítica eleva aún más las consecuencias. Muchas organizaciones utilizan objetivos de nivel de servicio que exigen una investigación inmediata de hallazgos críticos. Algunas bloquean lanzamientos de software o requieren excepciones formales hasta resolver la exposición reportada.

Para un componente integrado como SQLite, el alcance resultante puede ser amplio. Los equipos pueden descubrir SQLite dentro de aplicaciones de escritorio, software móvil, navegadores, herramientas de desarrollo o paquetes de sistemas operativos.

Encontrar la biblioteca no establece la exposición. Solo inicia el análisis. Los defensores aún necesitan una versión afectada, una ruta de código alcanzable, una entrada realista de atacante y una consecuencia de seguridad demostrada.

Un mecanismo fabricado hace que esa evaluación sea inusualmente costosa. Los ingenieros pueden inspeccionar rutas de integración, comparar versiones de paquetes, buscar en árboles de código fuente, contactar con proveedores y preparar actualizaciones de emergencia antes de descubrir que la supuesta función nunca existió.

El repositorio original también creó una apariencia de volumen. Su historial público enumeraba docenas de entradas con nombres de CVE, incluidos los seis registros de SQLite. La cantidad puede hacer que una fuente parezca productiva incluso cuando la calidad de la evidencia es baja.

JFrog dijo que revisó 55 avisos asociados con la misma cuenta. La empresa clasificó 54 como fabricados y describió uno como un error real rodeado de metadatos CVE no verificados.

Ese sigue siendo el resultado de auditoría reportado por JFrog, no una determinación universal sobre cada registro de cada base de datos. Aun así, los hallazgos detallados sobre SQLite ofrecen motivos reproducibles para cuestionar el lote.

El incidente también llegó a un ecosistema que ya experimentaba presión de revisión. En 2024, NIST reconoció públicamente un creciente retraso en el análisis de la National Vulnerability Database.

El anuncio del programa de la agencia indicó que el retraso reflejaba un mayor volumen de software y vulnerabilidades, además de un cambio en el apoyo interinstitucional. NIST afirmó que estaba priorizando los informes más significativos y añadiendo apoyo.

Un retraso no significa que NVD acepte todas las afirmaciones sin escrutinio. Tampoco este caso demuestra que todos los registros enriquecidos sean poco fiables. Sí muestra que la capacidad de procesamiento y el volumen de envíos determinan la rapidez con la que se corrigen los metadatos engañosos.

El modelo Authorized Data Publisher de CISA distribuye el trabajo de enriquecimiento entre organizaciones participantes. Ese enfoque puede ampliar la capacidad, pero también produce registros elaborados a partir de varias capas de información enviada y derivada.

La distinción importante es entre identidad, descripción y validación. Un CVE identifica una afirmación. Una descripción resume esa afirmación. La reproducción y la revisión del código fuente determinan si el mecanismo técnico se sostiene.

Esos pasos suelen aparecer juntos en una única página de vulnerabilidad, lo que anima a los lectores a tratarlos como un único juicio. El caso de SQLite muestra por qué los equipos de seguridad deben separarlos.

Los lectores de Hacker News reconocieron la consecuencia institucional. Si una prosa técnica plausible puede viajar más lejos que la evidencia funcional, entonces el canal de vulnerabilidades se vuelve vulnerable al mismo problema de escalado que afecta a otros contenidos generados por IA.

Un informe crea una carga de revisión moderada. Docenas de informes automatizados crean una cola. Miles pueden desviar la escasa atención experta de vulnerabilidades genuinas.

La inversión central es automatización frente a verificación

La automatización de seguridad amplificó los registros cuestionables más rápido de lo que los revisores humanos podían refutarlos.

La automatización es valiosa porque las organizaciones modernas no pueden examinar manualmente cada componente y aviso. Las herramientas de análisis de composición de software relacionan los paquetes instalados con registros de vulnerabilidades y luego priorizan los hallazgos por gravedad y alcance.

Ese modelo presupone que los registros entrantes contienen suficiente verdad como para justificar la primera respuesta. Tolera la incertidumbre, pero sigue dependiendo de que los identificadores, versiones, asignaciones de productos y descripciones técnicas estén vinculados a software real.

Los avisos disputados de SQLite explotaron esa suposición, de manera intencionada o no. Se parecían a informes de vulnerabilidades normales a nivel estructural. Nombraban funciones, versiones, clases de debilidad, impactos y entradas de ejemplo.

Los detalles creaban una ilusión de especificidad. Sin embargo, la especificidad no es exactitud. El nombre de una función puede sonar propio de una base de código y, aun así, estar ausente de la versión citada.

Los LLM son especialmente adecuados para producir este patrón. Pueden generar lenguaje de seguridad coherente recombinando conceptos comunes como punteros colgantes, SQL manipulado, corrupción del montón y ejecución remota.

Un modelo no necesita un exploit funcional para redactar una narrativa de explotación persuasiva. A menos que su resultado se base en el árbol de código fuente versionado real, puede conectar términos técnicos auténticos mediante una cadena causal inventada.

Los seis registros de SQLite mostraban varios fallos de fundamentación habituales.

Primero, mezclaban código de distintos períodos. Una función introducida durante 2025 aparecía en una afirmación contra SQLite 3.41.0, una versión de un estado anterior del código.

Segundo, trataban un comportamiento de implementación ordinario como desasignación. Reciclar un índice de registro no equivale a liberar memoria del montón, aunque ambos impliquen gestión de recursos.

En tercer lugar, inventaron cambios de respaldo. Un supuesto parche en 3.51.3 no correspondía a ningún cambio en el archivo fuente pertinente.

En cuarto lugar, proporcionaron entradas que fallaban antes de alcanzar la supuesta ruta vulnerable. Un error del analizador no puede demostrar un fallo de memoria en una lógica de ejecución posterior.

En quinto lugar, citaron ubicaciones fuera del archivo fuente. Esto equivale, en seguridad de software, a citar una página que no existe.

Cada fallo podía detectarse mediante comprobaciones sencillas. El desafío consiste en realizarlas antes de que los sistemas posteriores propaguen el registro.

Un revisor necesita la versión exacta afectada, la configuración de compilación, la entrada de prueba de concepto y las herramientas de detección. A continuación, debe confirmar que la ejecución alcanza el código señalado y produce el comportamiento de memoria afirmado.

Este trabajo es más lento que generar la acusación. Ese desequilibrio es la amenaza central.

El caso se asemeja a la economía del spam. Producir una propuesta plausible cuesta menos que refutarla. La automatización amplía la brecha porque quien la presenta puede escalar la generación de texto, mientras que los mantenedores y analistas aún necesitan inspeccionar el código.

La asimetría empeora cuando los sistemas posteriores asignan urgencia según la gravedad. Una etiqueta de 9.8 adelanta un informe frente a problemas con puntuaciones inferiores que podrían tener exploits confirmados, rutas de código accesibles e interés activo de atacantes.

En esas condiciones, los falsos positivos no son simplemente molestos. Distorsionan la priorización.

Los equipos pueden responder añadiendo más IA, pero eso crea un riesgo de segundo orden. Un agente de remediación automatizado podría buscar una función inventada, recomendar una actualización irrelevante o generar un parche para código no relacionado.

También podría modificar una dependencia únicamente para satisfacer un ticket. Cualquier cambio de código innecesario conlleva riesgo de regresiones, especialmente cuando se aplica bajo plazos de emergencia.

Esto no hace que la IA sea inadecuada para la investigación de seguridad. Los modelos pueden ayudar a generar casos de prueba, explicar código desconocido, agrupar informes duplicados y asistir a los revisores en la navegación del código fuente.

El límite debe ser la evidencia. La IA puede proponer una hipótesis, pero el proceso no debería tratar texto generado como un resultado confirmado. Un informe creíble necesita una ruta reproducible desde la entrada hasta el código afectado y un impacto observable.

Los mantenedores también aportan un contexto esencial. La guía de vulnerabilidades oficial de SQLite afirma que terceros crean CVE sobre SQLite, a menudo sin la participación de los desarrolladores principales.

El proyecto advierte que muchos problemas reportados de SQLite requieren que un atacante ejecute SQL arbitrario o envíe un archivo de base de datos malicioso. Esas condiciones previas excluyen muchas implementaciones habituales.

SQLite también distingue entre errores y vulnerabilidades de seguridad. Un fallo accesible únicamente después de que un atacante ya controle SQL arbitrario puede añadir poca capacidad más allá de la vulnerabilidad de inyección original.

Esta postura puede debatirse, especialmente cuando el SQL no confiable o los archivos de base de datos forman parte del diseño de un producto. Sin embargo, demuestra por qué una puntuación numérica no puede sustituir a un modelo de amenazas.

En este incidente, el fallo ocurrió incluso antes. El problema no era una consecuencia exagerada de un error real. Las pruebas de JFrog indicaron que los seis errores descritos no existían tal como se reportaron.

En qué deberían confiar los equipos de seguridad en lugar de una puntuación

Un CVE crítico recién publicado debería desencadenar una verificación estructurada, no una creencia automática ni un descarte automático.

La respuesta equivocada sería desconfiar de todo el sistema CVE. Las vulnerabilidades reales siguen apareciendo por los mismos canales, y retrasar la acción puede exponer a las organizaciones a daños graves.

La mejor respuesta es separar el triaje inicial de la remediación confirmada. Una puntuación crítica puede justificar una revisión inmediata sin predeterminar la conclusión de esa revisión.

Empiece por la corroboración del proveedor o mantenedor. Consulte la página oficial de seguridad, las notas de lanzamiento, el historial del código fuente, el rastreador de problemas y los commits de parches del proyecto afectado.

SQLite ahora enumera los seis identificadores en disputa como irreproducibles y aparentes alucinaciones de IA. Esta posición oficial constituye una evidencia más sólida que el silencio por sí solo, ya que refleja una evaluación directa del proyecto.

El silencio aún admite varias explicaciones. Los mantenedores podrían estar investigando en privado, preparando un lanzamiento coordinado o simplemente no conocer el registro. Por ello, la ausencia en la página de un proveedor debería plantear una pregunta, no resolverla.

A continuación, inspeccione las referencias del registro. Un informe creíble sobre seguridad de memoria debería señalar una versión, una ruta de código, un reproductor, un rastro de fallo, una salida de sanitizador, una corrección o una discusión de los mantenedores.

No todas las divulgaciones legítimas pueden publicar todas las evidencias de inmediato. Los embargos y el riesgo de exploits a veces limitan los detalles. Sin embargo, un registro anónimo sin historial de parches y con metadatos contradictorios merece un escrutinio adicional.

La precisión de la versión es otra comprobación de alto valor. Busque en la versión objetivo exacta cada función y estructura nombradas. Confirme que los números de línea citados correspondan a la lógica pertinente.

Esta prueba expuso rápidamente varias afirmaciones sobre SQLite. También escala mejor que un análisis completo de exploits, ya que las comprobaciones básicas del código fuente pueden automatizarse sin decidir si la vulnerabilidad es real.

Después, reproduzca la prueba de concepto en un entorno controlado. Utilice el código fuente oficial del proyecto, los ajustes de compilación documentados y un detector de tiempo de ejecución adecuado.

Un fallo por sí solo no demuestra el impacto completo descrito en el aviso. Los revisores deben establecer por qué ocurrió el fallo, si la entrada alcanza una interfaz compatible y si un atacante realista controla esa entrada.

Del mismo modo, una reproducción fallida no siempre refuta una vulnerabilidad. Las diferencias de compilador, arquitectura, indicadores de características, comportamiento del asignador o estado del entorno pueden afectar a los resultados.

El caso de SQLite ofreció contradicciones más sólidas que una sola prueba sin fallo. Los investigadores combinaron una reproducción fallida con funciones ausentes, firmas incorrectas, referencias de línea imposibles y correcciones inexistentes.

Esa combinación respalda un rechazo con confianza porque las inconsistencias independientes convergen en la misma conclusión.

Los equipos también deberían evaluar la accesibilidad dentro de su propio producto. La lista reciente de CVE de SQLite distingue repetidamente entre fallos de la biblioteca principal y extensiones opcionales, herramientas de línea de comandos, envoltorios y aplicaciones independientes.

Un producto puede incluir el nombre SQLite sin exponer el componente pertinente. Un escáner que solo coincide con la identidad del paquete puede exagerar el riesgo incluso cuando el CVE subyacente es válido.

Los programas de seguridad pueden formalizar estas comprobaciones mediante estados de evidencia.

Un registro nuevo puede comenzar como reportado. Puede pasar a corroborado cuando el proveedor lo reconoce, a reproducido cuando las pruebas confirman el comportamiento y a aplicable cuando la implementación de la organización expone la ruta.

La urgencia de la remediación debería reflejar las cuatro dimensiones: gravedad, evidencia, accesibilidad y explotación. La gravedad por sí sola describe una consecuencia técnica hipotética bajo los supuestos del registro.

Esta política también proporciona a los auditores un rastro más claro. En lugar de suprimir una alerta de escáner sin explicación, los analistas pueden registrar qué versión del código fuente inspeccionaron, qué probaron y por qué la ruta es inaccesible.

Mantener esa evidencia es un problema de gestión del conocimiento tanto como un problema de seguridad. Los equipos de ingeniería necesitan enlaces buscables entre avisos, inventarios de dependencias, resultados de pruebas, excepciones y decisiones de actualización.

Una base de conocimiento técnico estructurada puede preservar esas decisiones entre equipos sin convertir cada alerta repetida en una nueva investigación.

Las organizaciones deberían ser cautelosas con la aplicación automatizada de parches durante la etapa de reporte. Un agente puede reunir referencias del código fuente y preparar un entorno de prueba, pero los cambios en producción necesitan evidencias de que el código afectado existe.

La misma regla se aplica a los resúmenes generados. Si un sistema condensa varias fuentes, debería preservar su estado y sus discrepancias. No debe convertir una acusación en una afirmación confirmada únicamente por legibilidad.

Nada de esto elimina los registros falsos. Los hace menos costosos al detectar evidencias débiles antes de que desencadenen un amplio trabajo de remediación.

Qué cambia a continuación la historia de Hacker News

La siguiente prueba es si la infraestructura de vulnerabilidades puede rechazar registros sin respaldo antes de que escáneres, agentes y sistemas de cumplimiento los traten como hechos.

Tres señales mostrarán si este incidente produce una respuesta duradera.

La primera es la resolución de los registros relacionados. CVE-2026-51302 ahora está rechazado, y SQLite clasifica los seis identificadores en disputa como errores inexistentes. Correcciones coherentes en NVD, los feeds de avisos y las bases de datos de escáneres demostrarían que los metadatos de rechazo se propagan eficazmente.

Una propagación incompleta dejaría a las organizaciones gestionando alertas obsoletas después de que la afirmación original se haya derrumbado. Los proveedores de seguridad deberían preservar la corrección y dejar de presentar un registro rechazado como una exposición crítica activa.

La segunda señal es un manejo más sólido de la evidencia en las fases de presentación y enriquecimiento. Los cambios útiles incluirían versiones afectadas verificables por máquina, commits de código fuente, entradas reproducibles y etiquetas más claras para afirmaciones no verificadas.

Exigir pruebas públicas para cada presentación crearía sus propios problemas. Algunas vulnerabilidades necesitan divulgación coordinada, y publicar un exploit demasiado pronto puede aumentar el riesgo.

El objetivo práctico no es una reproducción pública universal. Es disponer de evidencia responsable ante las organizaciones encargadas de validarla, junto con etiquetas de confianza visibles en los sistemas posteriores.

La tercera señal es cómo la automatización de seguridad maneja fuentes contradictorias. Un sistema maduro debería detectar cuando un CVE menciona una función ausente, entra en conflicto con una página oficial del proyecto o queda rechazado después de su incorporación.

Debería reducir la confianza, reabrir decisiones anteriores y notificar a los equipos afectados. No debería seguir generando trabajo urgente a partir de una instantánea obsoleta.

Aún existe incertidumbre sobre el uso de IA en las presentaciones originales. Los clasificadores de texto no pueden establecer la autoría de forma fiable, y ninguna evidencia técnica pública demuestra qué modelo o flujo de trabajo produjo los avisos.

Esa incertidumbre no debilita la lección central. Los informes de vulnerabilidades escritos por humanos también pueden ser erróneos, fabricados o exagerados. El riesgo de escalado crece cuando la generación barata se encuentra con una incorporación automática.

La discusión en Hacker News hizo visible este episodio de SQLite porque la contradicción era excepcionalmente clara. Los registros críticos señalaban código que los investigadores pudieron demostrar que no existía.

Los casos futuros serán más difíciles. Un aviso generado podría referirse a funciones reales, producir un fallo auténtico y aun así inventar la explotabilidad o las versiones afectadas. Esa mezcla de verdad y fabricación exige una revisión más profunda.

Por ello, los líderes de seguridad deberían formular una pregunta directa sobre sus propios procesos: ¿qué ocurre después de que llega un registro crítico, pero antes de que las personas comiencen a modificar sistemas de producción?

Si la respuesta es solo “el escáner abre un ticket”, la organización ha automatizado la recepción sin automatizar el escepticismo.

Un flujo de trabajo mejor reúne declaraciones de proveedores, evidencia del código fuente, mapeos de versiones, datos de accesibilidad y resultados de reproducción. Entonces, las personas pueden concentrar su atención en juicios no resueltos en lugar de en una recopilación mecánica.

Los desarrolladores también deberían evitar la reacción exagerada opuesta. El descubrimiento de registros falsos de SQLite no hace que los nuevos informes de vulnerabilidades sean seguros de ignorar.

Trate el identificador como una pista. Trate la gravedad como una estimación inicial. Trate el código, el reproductor, la respuesta del mantenedor y el contexto de su implementación como la evidencia.

Este enfoque preserva el valor de la nomenclatura compartida de vulnerabilidades sin otorgar autoridad automática a cada entrada de apariencia oficial.

El caso de SQLite llegó a Hacker News porque condensó un problema más amplio en una sola corrección. No se demostró que la base de datos contuviera la vulnerabilidad crítica anunciada. Se demostró que el proceso de gestión de vulnerabilidades aceptaba una descripción convincente antes de que alguien verificara su código.

Los equipos de seguridad disponen ahora de una prueba práctica. Revisen cómo fluyen los CVE rechazados a través de escáneres, tickets y agentes de IA, y añadan una puerta de evidencia antes de la remediación. Si un sistema no puede distinguir entre una acusación publicada y una vulnerabilidad reproducida, este incidente se repetirá con un objetivo menos evidente.