¿Qué es Fluid Attacks Database? Un mapa gratuito de los CVE a las correcciones y los estándares

¿Qué es una base de datos de vulnerabilidades?

Una base de datos de vulnerabilidades es un catálogo de fallas de seguridad conocidas. Cada entrada tiene un identificador, el software y las versiones afectadas, y los datos necesarios para medir el riesgo. Las fuentes públicas suelen cumplir uno de tres propósitos:

• Listas de CVE. El CVE Program, que opera MITRE, asigna a cada vulnerabilidad conocida públicamente un ID como CVE-2025-67635. La National Vulnerability Database, a cargo del NIST, agrega puntajes de severidad y las configuraciones de producto que afecta cada CVE.

• Avisos de paquetes. OSV y la GitHub Advisory Database asocian las vulnerabilidades con las versiones de paquetes de código abierto. Un escáner de dependencias los lee para indicarte a qué versión actualizar.

• Inteligencia sobre explotación. El catálogo Known Exploited Vulnerabilities (KEV) de la CISA enumera los CVE que los atacantes ya usan en ataques reales. El Exploit Prediction Scoring System (EPSS) de FIRST estima la probabilidad de que un CVE se explote en los próximos 30 días.

Un cuarto tipo es más raro: una base de datos que conecta cada falla con su corrección y con los controles que exigen esa corrección. Saber que existe una falla es solo el punto de partida para un equipo que debe entregar una corrección y responder a una auditoría. Este es el tipo que describe el resto de este artículo.

Corrige la clase, no la instancia: la idea detrás de una base de datos pública de vulnerabilidades

En 2019, en un artículo sobre por qué los CEO deberían hablar de los defectos de software, escribimos que nuestra base de datos funciona como «una cadena unificadora»: un criterio para clasificar hallazgos de modo que los clientes puedan decidir por dónde empezar a corregir. Esa idea sigue dando forma a la base de datos pública de vulnerabilidades. Un CVE es una instancia de una falla en un producto, mientras que una debilidad es la clase que hay detrás de muchas instancias. La base de datos asocia más de 340.000 registros de vulnerabilidades con un catálogo de más de 380 debilidades, y escribimos correcciones para la debilidad y no para cada CVE: más de 2.000 correcciones cubren más de 320 debilidades en más de 20 lenguajes.

Un desarrollador que aprende la corrección de la debilidad 004, ejecución remota de comandos, puede reutilizarla para cada CVE de esa clase, porque el error en el código es el mismo aunque el producto no lo sea. Nuestra plataforma reporta los hallazgos con los mismos ID de debilidad, de modo que un hallazgo en un informe de pentest y su corrección en la base de datos comparten un mismo vocabulario.

Nuestra plataforma enlaza cada debilidad con su página en Fluid Attacks Database.

Un cambio de código cierra una falla, pero no demuestra nada ante un auditor, que necesita saber qué control satisface el cambio. Por eso, cada debilidad de la base de datos conduce al menos a uno de los más de 180 requisitos de seguridad independientes de la tecnología de la base. Cada requisito se asocia, a su vez, con los estándares que lo exigen, desde PCI DSS hasta ISO/IEC 27001; por ejemplo, el control 1.2.2 de PCI DSS v4.0 se asocia con el requisito 266, «Deshabilitar funcionalidades inseguras». Nuestras pruebas de seguridad se refieren a los mismos requisitos, por lo que la base de datos sigue la lógica de nuestras pruebas y no solo la de los feeds de CVE.

Controles de PCI DSS v4.0 y los requisitos de seguridad que los cubren.

Ocho secciones, desde los registros de CVE hasta las reglas de detección

Esta base de datos pública de vulnerabilidades tiene ocho secciones, y cada una responde una pregunta distinta. Los conteos de la tabla son valores mínimos, porque las fuentes de datos siguen agregando registros; la página de inicio de cada sección muestra el valor actualizado.

Cada sección usa su propio formato de ID. Los registros de vulnerabilidades empiezan con FLAT (por ejemplo, FLAT-CII5B), las debilidades y los requisitos usan un número de tres dígitos (317, 072), y las reglas llevan como prefijo la técnica de detección (SAST-LAH1N). Si quieres ver cómo las clases de debilidades guían nuestra propia investigación de vulnerabilidades, lee cómo nuestro flujo de trabajo de SAST con IA encuentra candidatos a CVE, que explica las categorías que explora el escáner.

Home de Fluid Attacks Database y sus ocho secciones.

Un registro rastreado de principio a fin: CVE-2025-67635 en Jenkins

CVE-2025-67635 es una denegación de servicio en la interfaz de línea de comandos de Jenkins: Jenkins no cierra correctamente las conexiones HTTP de la CLI cuando el flujo de la conexión se corrompe, y un atacante no autenticado puede aprovecharlo para provocar la caída del servicio. Explicamos cómo funciona en nuestro análisis de la denegación de servicio sin autenticación en la CLI de Jenkins. Su registro en la base de datos de vulnerabilidades muestra la cadena completa, y los cinco pasos siguientes la recorren desde el aviso de seguridad hasta la auditoría.

Un registro: del CVE-2025-67635 a su debilidad, requisito, correcciones y reglas. Imagen ilustrativa. Consulta la cadena completa en la debilidad 317.

1. El registro de la vulnerabilidad

El registro de vulnerabilidad FLAT-CII5B agrupa el CVE con sus alias en NVD, OSV y GCVE, y muestra la fecha de divulgación pública, el 10 de diciembre de 2025. Los dos paquetes Maven afectados son org.jenkins-ci.main:cli y org.jenkins-ci.main:jenkins-core. Los rangos vulnerables son las versiones desde la 2.529 hasta la 2.541 sin incluirla, y todas las versiones anteriores a la 2.528.3; las versiones con parche son la 2.541 y la 2.528.3. El registro también incluye el CWE que asigna la fuente del aviso, CWE-404 (cierre o liberación incorrectos de recursos), y un enlace al commit que corrigió la falla.

2. La debilidad

El registro apunta a la debilidad 317, asignación incorrecta de recursos (fuga de memoria). Su descripción dice que el sistema puede no liberar los recursos de los flujos de entrada y salida que abrió, porque el código fuente no los cierra de forma explícita. Ese es el error de Jenkins en términos generales: una conexión que nadie cierra conserva sus recursos. La página enumera un impacto, el agotamiento de los recursos del servidor, y una recomendación: cerrar de forma explícita los flujos de salida justo después de usarlos. También indica un tiempo de remediación estimado de 30 minutos, que le permite a un equipo planear el trabajo antes de abrir el código.

El vínculo entre un registro y su debilidad es automático. La base de datos compara el CWE del aviso con nuestro catálogo de debilidades y, cuando varias debilidades encajan, un modelo de lenguaje (embeddings) elige la más cercana. Ninguna persona revisa cada asociación, así que, cuando encontramos un error, lo corregimos con un parche manual.

Debilidad 317 con sus requisitos, reglas y correcciones.

3. Los requisitos

La debilidad 317 se asocia con seis requisitos: 072, 146, 158, 164, 173 y 345. El requisito 072, «Establecer un tiempo máximo de respuesta», es el que mejor coincide con el caso de Jenkins: cuando las conexiones permanecen abiertas, el servidor se queda sin recursos y su tiempo de respuesta crece hasta que deja de responder. Su resumen exige que el tiempo de respuesta con la concurrencia máxima esperada no supere los 5 segundos. Un requisito enuncia un objetivo de seguridad sin nombrar un lenguaje ni un framework, por lo que el mismo texto se aplica a un servicio en Java y a uno en Go. Los otros cinco cubren formas relacionadas de uso indebido de memoria y recursos, como el requisito 345, «Establecer protecciones contra desbordamientos».

4. Las correcciones y la regla

La debilidad tiene correcciones en varios lenguajes, entre ellos C#, Dart, Go, Java, JavaScript/TypeScript, PHP, Python, Ruby, Rust, Scala y Swift. Cada corrección muestra código no conforme, una explicación y código conforme, para que un desarrollador pueda comparar ambas versiones lado a lado antes de cambiar algo en el repositorio. La corrección en Java para la debilidad 317 muestra un servlet que abre el flujo de entrada de una solicitud y nunca lo cierra. No es el código de Jenkins, pero es la misma clase de error. La versión conforme abre el flujo en un bloque try-with-resources, que lo cierra incluso cuando ocurre una excepción:

try (InputStream is = req.getInputStream()) {

    // handling the input stream

    // ...

} catch (IOException e) {

    // handle exception

}

try (InputStream is = req.getInputStream()) {

    // handling the input stream

    // ...

} catch (IOException e) {

    // handle exception

}

try (InputStream is = req.getInputStream()) {

    // handling the input stream

    // ...

} catch (IOException e) {

    // handle exception

}

try (InputStream is = req.getInputStream()) {

    // handling the input stream

    // ...

} catch (IOException e) {

    // handle exception

}

La debilidad también tiene tres reglas de detección, para C#, Java y Rust. La regla de Java, SAST-LAH1N, marca código en el que una entrada HTTP no validada controla la asignación de memoria, una vía hacia la denegación de servicio.

Corrección en Java para la debilidad 317: un servlet que nunca cierra su flujo.

5. Los estándares

El requisito 072 se asocia con más de 10 estándares, entre ellos CAPEC, GDPR, IEC 62443, el OWASP Application Security Verification Standard (ASVS), el OWASP API Security Top 10 y el OWASP Top 10 for LLM Applications.

Un auditor no pregunta por el CVE-2025-67635; un auditor pregunta si la aplicación mantiene su tiempo de respuesta bajo carga y libera los recursos que usa. Con la cadena en la mano, el equipo puede mostrar el requisito, el código que lo satisface y los estándares que lo citan, todo desde un solo registro.

La página de PCI DSS funciona en sentido inverso, pues enumera cada control de la v4.0 con los requisitos que lo cubren.

Señales de explotación en un registro y las fuentes que las respaldan

Cada registro de vulnerabilidad de la base de datos pública de vulnerabilidades reúne sus señales de riesgo en un solo panel, y el panel se actualiza a medida que lo hacen las fuentes. La tabla enumera cada señal, qué te dice y su valor cuando rastreamos el registro del CVE-2025-67635 (FLAT-CII5B).

Lee las señales en conjunto, no solo el puntaje base. El puntaje base de 7,5 describe el impacto potencial en un entorno genérico. Las señales de explotación muestran otro panorama: cuando rastreamos el registro, EPSS daba una probabilidad de explotación de 0,56 % en los próximos 30 días, y ni KEV ni las fuentes de exploits mostraban evidencia de un ataque. El puntaje ajustado de 4,6 también es más bajo, pero su métrica de madurez del exploit toma un valor por defecto, por lo que no lo interpretamos como prueba de que no exista un exploit.

VLAI es un modelo del CIRCL que lee la descripción de un aviso y predice un nivel de severidad, no un puntaje. Para este registro predice Alta, con 97 % de confianza en ese nivel. Es el mismo nivel que el 7,5 original, mientras que el puntaje ajustado cae en Media, así que las señales no siempre coinciden, y quien hace el triaje debe verlas todas. Escribimos sobre esta brecha entre los puntajes base y la explotación real en repensar la severidad de las vulnerabilidades.

IMAGEN (capturas en inglés, igual que en la versión final):

Alt: Registro del CVE-2025-67635 con puntajes EPSS, KEV y CVSS | Caption: Señales de explotación y severidad en el registro del CVE-2025-67635.

Los datos provienen de más de 15 fuentes de datos de vulnerabilidades en dos grupos. Entre los proveedores de avisos están CVE.org, OSV, la GitHub Security Advisory Database, Red Hat Security Advisories, el Arch Linux Security Tracker, la GitLab Advisory Database y la NVD. Entre las fuentes de inteligencia de severidad y explotación están VulnCheck, ENISA, CIRCL, EPSS, CISA KEV, Exploit-DB, Nuclei Templates, PoC-in-GitHub, el Metasploit Framework y GCVE.

La página enumera la licencia de cada fuente, y cada registro lista como alias los ID que otras fuentes usan para la misma falla. Las vulnerabilidades que divulga nuestro propio equipo aparecen en los avisos de seguridad de Fluid Attacks.

¿Qué base de datos de vulnerabilidades vincula un CVE con su corrección y su regla de cumplimiento?

La comunidad de seguridad se apoya en varias fuentes públicas, y cada una cumple una función específica. La NVD, a cargo del NIST, puntúa y describe cada CVE. El catálogo KEV de la CISA enumera los CVE que los atacantes ya usan. OSV asocia las vulnerabilidades con versiones de paquetes de código abierto, y la GitHub Advisory Database revisa los avisos paquete por paquete.

Ninguna muestra cómo escribir el código seguro ni qué control de cumplimiento cubre una corrección, y la base de datos pública de vulnerabilidades de Fluid Attacks toma datos de estas fuentes para agregar esa capa:

Revisamos un registro real de cada fuente: el registro de la NVD para Log4Shell, el registro de OSV para el aviso de Log4j, el aviso de GitHub para la falla de contaminación de prototipos de lodash y el propio catálogo KEV.

Usa la NVD u OSV para saber que existe un CVE y qué versión lo elimina.

Usa Fluid Attacks Database cuando debas corregir el código y mostrar qué control satisface la corrección. Nuestra plataforma ya funciona así: cada debilidad que reportan nuestros escaneos SAST, SCA y DAST o nuestros pentesters enlaza con su página en la base de datos, y cada dependencia vulnerable enlaza con su registro.

Esa es la filosofía detrás de esta base de datos de vulnerabilidades: un registro es útil cuando quien lo lee puede actuar con él. Para ver la cadena de tu propio stack, busca un CVE de tu último escaneo en Fluid Attacks Database.

Un hallazgo en la plataforma de Fluid Attacks enlaza con su registro en la base de datos.

Opciones de corrección para una dependencia transitiva, tal como las muestra nuestra plataforma.

Preguntas frecuentes

¿Cómo encuentro un registro si solo tengo el ID del CVE?

Agrega el ID del CVE a la dirección de la sección de vulnerabilidades, con el patrón /vul/[CVE ID]/. La página redirige al ID de Fluid Attacks del registro: por ejemplo, la dirección del CVE-2026-41242 abre el registro FLAT-LBEWZ. También puedes buscar por CVE, nombre de paquete o ID de aviso en la barra de búsqueda que aparece en la parte superior de cualquier página.

¿Cómo vincula la base de datos un CVE con una debilidad?

De forma automática. La base de datos cruza el CWE de cada aviso con nuestro catálogo de debilidades y, cuando varias debilidades encajan, un modelo de lenguaje (embeddings) elige la más parecida. Ninguna persona revisa cada asociación, por lo que, si ocurre un desajuste ocasional, lo corregimos con un parche manual cuando lo detectamos. Para verificar una asociación, abre el registro y compara la descripción de su debilidad con la del aviso.

¿Cómo compruebo si una versión de un paquete de mi proyecto está afectada?

Abre la página del componente, con el patrón /cmp/[ecosystem]/[package]/. Por ejemplo, la página del componente pyjwt en PyPI enumera cada versión del paquete con su estado y su severidad máxima. La sección de Componentes abarca más de 10 ecosistemas, entre ellos npm, PyPI, Maven, Go, Cargo y NuGet.

¿Puedo consultar la base de datos desde un script o un pipeline de CI?

Sí. Los endpoints JSON son públicos y no requieren autenticación. El endpoint /vul/data.json devuelve una lista paginada, con 100 elementos por página de forma predeterminada, y /vul/[id]/data.json devuelve un registro. La lista acepta filtros como search, severity, ecosystem, epss y fix. El archivo llms.txt de la base de datos enumera cada endpoint y cada filtro.

¿Qué puedo hacer si un registro no muestra una versión con parche?

Una corrección de código no depende de una nueva versión del paquete. Abre la debilidad del registro: sus correcciones muestran cómo eliminar la falla de tu propio código, y sus requisitos indican el control que debes mantener mientras el proveedor publica un parche.

¿Cómo uso la base de datos de vulnerabilidades para preparar evidencia para una auditoría de PCI DSS?

Abre la página de PCI DSS de la base de datos. Su tabla de controles y requisitos enumera cada control de PCI DSS v4.0 con los requisitos que lo cubren. Desde cada requisito puedes abrir las debilidades que lo incumplen y sus correcciones. De ese modo, cada hallazgo de tu informe tiene un control, una causa y una corrección.