O que é a Fluid Attacks Database? Um mapa gratuito dos CVEs até as correções e os padrões

O que é um banco de dados de vulnerabilidades?

Um banco de dados de vulnerabilidades é um catálogo de falhas de segurança conhecidas. Cada entrada tem um identificador, o software e as versões afetadas, e os dados necessários para medir o risco. As fontes públicas costumam cumprir um de três propósitos:

• Listas de CVE. O CVE Program, operado pela MITRE, atribui a cada vulnerabilidade conhecida publicamente um ID como CVE-2025-67635. A National Vulnerability Database, mantida pelo NIST, acrescenta pontuações de severidade e as configurações de produto que cada CVE afeta.

• Avisos de pacotes. O OSV e a GitHub Advisory Database associam as vulnerabilidades às versões de pacotes de código aberto. Um scanner de dependências os lê para indicar a qual versão atualizar.

• Inteligência sobre exploração. O catálogo Known Exploited Vulnerabilities (KEV) da CISA lista os CVEs que os atacantes já usam em ataques reais. O Exploit Prediction Scoring System (EPSS) do FIRST estima a probabilidade de um CVE ser explorado nos próximos 30 dias.

Um quarto tipo é mais raro: um banco de dados que conecta cada falha à sua correção e aos controles que exigem essa correção. Saber que uma falha existe é apenas o ponto de partida para uma equipe que precisa entregar uma correção e responder a uma auditoria. É esse o tipo que o restante deste artigo descreve.

Corrija a classe, não a instância: a ideia por trás de um banco de dados público de vulnerabilidades

Em 2019, em um artigo sobre por que os CEOs deveriam falar sobre defeitos de software, escrevemos que nosso banco de dados funciona como “uma cadeia unificadora”: um critério para classificar achados de modo que os clientes possam decidir por onde começar a corrigir. Essa ideia continua moldando o banco de dados público de vulnerabilidades. Um CVE é uma instância de uma falha em um produto, enquanto uma fraqueza é a classe por trás de muitas instâncias. O banco de dados associa mais de 340.000 registros de vulnerabilidades a um catálogo de mais de 380 fraquezas, e escrevemos correções para a fraqueza e não para cada CVE: mais de 2.000 correções cobrem mais de 320 fraquezas em mais de 20 linguagens.

Um desenvolvedor que aprende a correção da fraqueza 004, execução remota de comandos, pode reutilizá-la para cada CVE dessa classe, porque o erro no código é o mesmo, ainda que o produto não seja. Nossa plataforma reporta os achados com os mesmos IDs de fraqueza, de modo que um achado em um relatório de pentest e sua correção no banco de dados compartilham um mesmo vocabulário.

Nossa plataforma vincula cada fraqueza à sua página na Fluid Attacks Database.

Uma mudança de código fecha uma falha, mas não demonstra nada a um auditor, que precisa saber qual controle a mudança satisfaz. Por isso, cada fraqueza do banco de dados leva a pelo menos um dos mais de 180 requisitos de segurança independentes de tecnologia do banco. Cada requisito, por sua vez, se associa aos padrões que o exigem, desde o PCI DSS até a ISO/IEC 27001; por exemplo, o controle 1.2.2 do PCI DSS v4.0 se associa ao requisito 266, “Desabilitar funcionalidades inseguras”. Nossos testes de segurança se referem aos mesmos requisitos, por isso o banco de dados segue a lógica dos nossos testes e não apenas a dos feeds de CVE.

Controles do PCI DSS v4.0 e os requisitos de segurança que os cobrem.

Oito seções, dos registros de CVE às regras de detecção

Este banco de dados público de vulnerabilidades tem oito seções, e cada uma responde a uma pergunta diferente. As contagens da tabela são valores mínimos, porque as fontes de dados continuam acrescentando registros; a página inicial de cada seção mostra o valor atualizado.

Cada seção usa seu próprio formato de ID. Os registros de vulnerabilidades começam com FLAT (por exemplo, FLAT-CII5B), as fraquezas e os requisitos usam um número de três dígitos (317, 072), e as regras levam como prefixo a técnica de detecção (SAST-LAH1N). Se você quiser ver como as classes de fraquezas orientam a nossa própria pesquisa de vulnerabilidades, leia como o nosso fluxo de trabalho de SAST com IA encontra candidatos a CVE, que explica as categorias que o scanner explora.

A página inicial da Fluid Attacks Database e suas oito seções.

Um registro rastreado do início ao fim: CVE-2025-67635 no Jenkins

O CVE-2025-67635 é uma negação de serviço na interface de linha de comando do Jenkins: o Jenkins não fecha corretamente as conexões HTTP da CLI quando o fluxo da conexão é corrompido, e um atacante não autenticado pode aproveitar isso para provocar a queda do serviço. Explicamos como funciona em nossa análise da negação de serviço sem autenticação na CLI do Jenkins. Seu registro no banco de dados de vulnerabilidades mostra a cadeia completa, e os cinco passos a seguir a percorrem do aviso de segurança até a auditoria.

Um registro: do CVE-2025-67635 à sua fraqueza, requisito, correções e regras. Imagem ilustrativa. Veja a cadeia completa na fraqueza 317.

1. O registro da vulnerabilidade

O registro de vulnerabilidade FLAT-CII5B agrupa o CVE com seus aliases na NVD, no OSV e no GCVE, e mostra a data de divulgação pública, 10 de dezembro de 2025. Os dois pacotes Maven afetados são org.jenkins-ci.main:cli e org.jenkins-ci.main:jenkins-core. Os intervalos vulneráveis são as versões da 2.529 até a 2.541, sem incluí-la, e todas as versões anteriores à 2.528.3; as versões corrigidas são a 2.541 e a 2.528.3. O registro também inclui o CWE atribuído pela fonte do aviso, CWE-404 (encerramento ou liberação inadequados de recursos), e um link para o commit que corrigiu a falha.

2. A fraqueza

O registro aponta para a fraqueza 317, alocação inadequada de recursos (vazamento de memória). Sua descrição diz que o sistema pode deixar de liberar os recursos dos fluxos de entrada e saída que abriu, porque o código-fonte não os fecha de forma explícita. Esse é o erro do Jenkins em termos gerais: uma conexão que ninguém fecha mantém seus recursos. A página lista um impacto, o esgotamento dos recursos do servidor, e uma recomendação: fechar de forma explícita os fluxos de saída logo após usá-los. Ela também indica um tempo de remediação estimado de 30 minutos, que permite a uma equipe planejar o trabalho antes de abrir o código.

O vínculo entre um registro e sua fraqueza é automático. O banco de dados compara o CWE do aviso com o nosso catálogo de fraquezas e, quando várias fraquezas se encaixam, um modelo de linguagem (embeddings) escolhe a mais próxima. Nenhuma pessoa revisa cada associação, então, quando encontramos um erro, nós o corrigimos com um patch manual.

Fraqueza 317 com seus requisitos, regras e correções.

3. Os requisitos

A fraqueza 317 se associa a seis requisitos: 072, 146, 158, 164, 173 e 345. O requisito 072, “Definir um tempo máximo de resposta”, é o que melhor corresponde ao caso do Jenkins: quando as conexões permanecem abertas, o servidor fica sem recursos e seu tempo de resposta cresce até que ele deixe de responder. Seu resumo exige que o tempo de resposta na concorrência máxima esperada não ultrapasse 5 segundos. Um requisito enuncia um objetivo de segurança sem citar uma linguagem nem um framework, de modo que o mesmo texto se aplica a um serviço em Java e a um em Go. Os outros cinco cobrem formas relacionadas de uso indevido de memória e recursos, como o requisito 345, “Estabelecer proteções contra estouros”.

4. As correções e a regra

A fraqueza tem correções em várias linguagens, entre elas C#, Dart, Go, Java, JavaScript/TypeScript, PHP, Python, Ruby, Rust, Scala e Swift. Cada correção mostra código não conforme, uma explicação e código conforme, para que um desenvolvedor possa comparar as duas versões lado a lado antes de mudar qualquer coisa no repositório. A correção em Java para a fraqueza 317 mostra um servlet que abre o fluxo de entrada de uma requisição e nunca o fecha. Não é o código do Jenkins, mas é a mesma classe de erro. A versão conforme abre o fluxo em um bloco try-with-resources, que o fecha mesmo quando ocorre uma exceção:

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

}

A fraqueza também tem três regras de detecção, para C#, Java e Rust. A regra de Java, SAST-LAH1N, sinaliza código em que uma entrada HTTP não validada controla a alocação de memória, um caminho para a negação de serviço.

Correção em Java para a fraqueza 317: um servlet que nunca fecha seu fluxo.

5. Os padrões

O requisito 072 se associa a mais de 10 padrões, entre eles CAPEC, GDPR, IEC 62443, o OWASP Application Security Verification Standard (ASVS), o OWASP API Security Top 10 e o OWASP Top 10 for LLM Applications.

Um auditor não pergunta pelo CVE-2025-67635; um auditor pergunta se a aplicação mantém seu tempo de resposta sob carga e libera os recursos que usa. Com a cadeia em mãos, a equipe pode mostrar o requisito, o código que o satisfaz e os padrões que o citam, tudo a partir de um único registro.

A página do PCI DSS funciona no sentido inverso, pois lista cada controle da v4.0 com os requisitos que o cobrem.

Sinais de exploração em um registro e as fontes que os respaldam

Cada registro de vulnerabilidade do banco de dados público de vulnerabilidades reúne seus sinais de risco em um único painel, e o painel é atualizado à medida que as fontes o são. A tabela lista cada sinal, o que ele informa e seu valor quando rastreamos o registro do CVE-2025-67635 (FLAT-CII5B).

Leia os sinais em conjunto, não apenas a pontuação base. A pontuação base de 7,5 descreve o impacto potencial em um ambiente genérico. Os sinais de exploração mostram outro cenário: quando rastreamos o registro, o EPSS indicava uma probabilidade de exploração de 0,56 % nos próximos 30 dias, e nem o KEV nem as fontes de exploits mostravam evidência de um ataque. A pontuação ajustada de 4,6 também é mais baixa, mas sua métrica de maturidade do exploit assume um valor padrão, por isso não a interpretamos como prova de que não existe um exploit.

O VLAI é um modelo do CIRCL que lê a descrição de um aviso e prevê um nível de severidade, não uma pontuação. Para este registro, ele prevê Alta, com 97 % de confiança nesse nível. É o mesmo nível do 7,5 original, enquanto a pontuação ajustada cai em Média, então os sinais nem sempre coincidem, e quem faz a triagem deve vê-los todos. Escrevemos sobre essa lacuna entre as pontuações base e a exploração real em repensar a severidade das vulnerabilidades.

Sinais de exploração e severidade no registro do CVE-2025-67635.

Os dados vêm de mais de 15 fontes de dados de vulnerabilidades em dois grupos. Entre os provedores de avisos estão a CVE.org, o OSV, a GitHub Security Advisory Database, os Red Hat Security Advisories, o Arch Linux Security Tracker, a GitLab Advisory Database e a NVD. Entre as fontes de inteligência de severidade e exploração estão VulnCheck, ENISA, CIRCL, EPSS, CISA KEV, Exploit-DB, Nuclei Templates, PoC-in-GitHub, o Metasploit Framework e o GCVE.

A página lista a licença de cada fonte, e cada registro lista como aliases os IDs que outras fontes usam para a mesma falha. As vulnerabilidades divulgadas pela nossa própria equipe aparecem nos avisos de segurança da Fluid Attacks.

Qual banco de dados de vulnerabilidades vincula um CVE à sua correção e à sua regra de conformidade?

A comunidade de segurança se apoia em várias fontes públicas, e cada uma cumpre uma função específica. A NVD, mantida pelo NIST, pontua e descreve cada CVE. O catálogo KEV da CISA lista os CVEs que os atacantes já usam. O OSV associa as vulnerabilidades a versões de pacotes de código aberto, e a GitHub Advisory Database revisa os avisos pacote por pacote.

Nenhuma delas mostra como escrever o código seguro nem qual controle de conformidade uma correção cobre, e o banco de dados público de vulnerabilidades da Fluid Attacks reúne dados dessas fontes para acrescentar essa camada:

Revisamos um registro real de cada fonte: o registro da NVD para o Log4Shell, o registro do OSV para o aviso do Log4j, o aviso do GitHub para a falha de poluição de protótipo do lodash e o próprio catálogo KEV.

Use a NVD ou o OSV para saber que um CVE existe e qual versão o elimina.

Use a Fluid Attacks Database quando precisar corrigir o código e mostrar qual controle a correção satisfaz. Nossa plataforma já funciona assim: cada fraqueza reportada pelos nossos scans de SAST, SCA e DAST ou pelos nossos pentesters se vincula à sua página no banco de dados, e cada dependência vulnerável se vincula ao seu registro.

Essa é a filosofia por trás deste banco de dados de vulnerabilidades: um registro é útil quando quem o lê pode agir com ele. Para ver a cadeia do seu próprio stack, busque na Fluid Attacks Database um CVE do seu último scan.

Um achado na plataforma da Fluid Attacks se vincula ao seu registro no banco de dados.

Opções de correção para uma dependência transitiva, como a nossa plataforma as mostra.

Perguntas frequentes

Como encontro um registro se só tenho o ID do CVE?

Acrescente o ID do CVE ao endereço da seção de vulnerabilidades, com o padrão /vul/[CVE ID]/. A página redireciona para o ID da Fluid Attacks do registro: por exemplo, o endereço do CVE-2026-41242 abre o registro FLAT-LBEWZ. Você também pode buscar por CVE, nome de pacote ou ID de aviso na barra de busca que aparece no topo de qualquer página.

Como o banco de dados vincula um CVE a uma fraqueza?

De forma automática. O banco de dados cruza o CWE de cada aviso com o nosso catálogo de fraquezas e, quando várias fraquezas se encaixam, um modelo de linguagem (embeddings) escolhe a mais parecida. Nenhuma pessoa revisa cada associação, portanto, se ocorrer uma divergência ocasional, nós a corrigimos com um patch manual quando a detectamos. Para verificar uma associação, abra o registro e compare a descrição de sua fraqueza com a do aviso.

Como verifico se uma versão de um pacote do meu projeto está afetada?

Abra a página do componente, com o padrão /cmp/[ecosystem]/[package]/. Por exemplo, a página do componente pyjwt no PyPI lista cada versão do pacote com seu status e sua severidade máxima. A seção de Componentes abrange mais de 10 ecossistemas, entre eles npm, PyPI, Maven, Go, Cargo e NuGet.

Posso consultar o banco de dados a partir de um script ou de um pipeline de CI?

Sim. Os endpoints JSON são públicos e não exigem autenticação. O endpoint /vul/data.json devolve uma lista paginada, com 100 itens por página por padrão, e /vul/[id]/data.json devolve um registro. A lista aceita filtros como search, severity, ecosystem, epss e fix. O arquivo llms.txt do banco de dados lista cada endpoint e cada filtro.

O que posso fazer se um registro não mostra uma versão corrigida?

Uma correção de código não depende de uma nova versão do pacote. Abra a fraqueza do registro: suas correções mostram como eliminar a falha do seu próprio código, e seus requisitos indicam o controle que você deve manter enquanto o fornecedor publica um patch.

Como uso o banco de dados de vulnerabilidades para preparar evidências para uma auditoria de PCI DSS?

Abra a página do PCI DSS no banco de dados. Sua tabela de controles e requisitos lista cada controle do PCI DSS v4.0 com os requisitos que o cobrem. A partir de cada requisito, você pode abrir as fraquezas que o descumprem e suas correções. Assim, cada achado do seu relatório tem um controle, uma causa e uma correção.