What is the Fluid Attacks Database? A free map from CVEs to fixes and standards

What is a vulnerability database?

A vulnerability database is a catalog of known security flaws. Each entry has an identifier, the software and versions affected, and the data needed to measure the risk. Public sources usually serve one of three purposes:

• CVE lists. The CVE Program, which MITRE operates, gives each publicly known vulnerability an ID such as CVE-2025-67635. The National Vulnerability Database, run by NIST, adds severity scores and the product configurations that each CVE affects.

• Package advisories. OSV and the GitHub Advisory Database map vulnerabilities to the versions of open-source packages. A dependency scanner reads them to tell you which version to upgrade to.

• Exploitation intelligence. The Known Exploited Vulnerabilities (KEV) catalog from CISA lists the CVEs that attackers already use in real attacks. The Exploit Prediction Scoring System (EPSS) from FIRST estimates the probability that a CVE will be exploited in the next 30 days.

A fourth type is rarer: a database that connects each flaw to its correction and to the controls that require that correction. Knowing that a flaw exists is only the starting point for a team that must ship a fix and answer an audit. This is the type that the rest of this post describes.

Fix the class, not the instance: The idea behind a public vulnerability database

In 2019, in a post about why CEOs should discuss software defects, we wrote that our database acts as "a unifying chain": a criterion to classify findings so that customers can decide where to start fixing. That idea still shapes the public vulnerability database. A CVE is one instance of a flaw in one product, while a weakness is the class behind many instances. The database maps more than 340,000 vulnerability records to a catalog of more than 380 weaknesses, and we write fixes for the weakness rather than for each CVE: more than 2,000 fixes cover more than 320 weaknesses in more than 20 languages.

A developer who learns the fix for weakness 004, remote command execution, can reuse it for every CVE of that class, because the mistake in the code is the same even when the product is not. Our platform reports findings with the same weakness IDs, so a finding in a pentest report and its fix in the database share one vocabulary.

Our platform links each weakness to its page in the Fluid Attacks Database.

A code change closes a flaw, but it does not prove anything to an auditor, who needs to know which control the change satisfies. For that reason, each weakness in the database leads to at least one of the database's more than 180 technology-independent security requirements. Each requirement then maps to the standards that ask for it, from PCI DSS to ISO/IEC 27001; for example, PCI DSS v4.0 control 1.2.2 maps to requirement 266, "Disable insecure functionalities". Our security tests refer to the same requirements, which is why the database follows the logic of our testing and not only the logic of CVE feeds.

PCI DSS v4.0 controls and the security requirements that cover them.

Eight sections, from CVE records to detection rules

This public vulnerability database has eight sections, and each one answers a different question. The counts in the table are floors, because the data sources keep adding records; the landing page of each section shows the live value.

Each section uses its own ID format. Vulnerability records start with FLAT (for example, FLAT-CII5B), weaknesses and requirements use a three-digit number (317, 072), and rules take the detection technique as a prefix (SAST-LAH1N). If you want to see how weakness classes guide our own vulnerability research, read how our AI SAST workflow finds CVE candidates, which explains the categories that the scanner explores.

The Fluid Attacks Database home and its eight sections.

One record traced end to end: CVE-2025-67635 in Jenkins

CVE-2025-67635 is a denial of service in the Jenkins command-line interface: Jenkins does not properly close HTTP-based CLI connections when the connection stream becomes corrupted, and an unauthenticated attacker can use that to cause the outage. We explained how it works in our analysis of the unauthenticated DoS in the Jenkins CLI. Its record in the vulnerability database shows the full chain, and the five steps below follow it from the advisory to the audit.

One record: from CVE-2025-67635 to its weakness, requirement, fixes and rules. Illustrative image. See the full chain in weakness 317.

1. The vulnerability record

The vulnerability record FLAT-CII5B groups the CVE with its aliases in NVD, OSV and GCVE, and it shows the public disclosure date, December 10, 2025. The two affected Maven packages are org.jenkins-ci.main:cli and org.jenkins-ci.main:jenkins-core. The vulnerable ranges are versions from 2.529 up to, but not including, 2.541, and every version before 2.528.3; the patched versions are 2.541 and 2.528.3. The record also carries the CWE that the advisory source assigns, CWE-404 (improper resource shutdown or release), and a link to the commit that fixed the flaw.

2. The weakness

The record points to weakness 317, improper resource allocation (memory leak). Its description says that the system may fail to release the inbound and outbound flow resources that it has opened, because the source code does not close them explicitly. That is the Jenkins mistake in general terms: a connection that nobody closes keeps its resources. The page lists one impact, exhausted server resources, and one recommendation: shut down outflows explicitly right after use. It also gives an expected remediation time of 30 minutes, which lets a team plan the work before it opens the code.

The link between a record and its weakness is automatic. The database compares the CWE of the advisory with our weakness catalog and, when several weaknesses fit, a language model (embeddings) picks the closest one. No person reviews each match, so when we find an error, we correct it with a manual patch.

Weakness 317 with its requirements, rules and fixes.

3. The requirements

Weakness 317 maps to six requirements: 072, 146, 158, 164, 173 and 345. Requirement 072, "Set maximum response time," is the closest match to the Jenkins case: when connections stay open, the server runs out of resources and its response time grows until it stops answering. Its summary asks that the response time under maximum expected concurrence stay at 5 seconds or less. A requirement states a security objective without naming a language or a framework, so the same text applies to a Java service and to a Go one. The other five cover related forms of memory and resource misuse, such as requirement 345, "Establish protections against overflows."

4. The fixes and the rule

The weakness has fixes in several languages, among them C#, Dart, Go, Java, JavaScript/TypeScript, PHP, Python, Ruby, Rust, Scala and Swift. Each fix shows non-compliant code, an explanation and compliant code, so a developer can compare both versions side by side before changing anything in the repository. The Java fix for weakness 317 shows a servlet that opens the input stream of a request and never closes it. It is not the Jenkins code, but it is the same class of mistake. The compliant version opens the stream in a try-with-resources block, which closes it even when an exception occurs:

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

}

The weakness also has three detection rules, for C#, Java and Rust. The Java rule, SAST-LAH1N, flags code in which unvalidated HTTP input controls memory allocation, a path to denial of service.

Java fix for weakness 317: a servlet that never closes its stream.

5. The standards

Requirement 072 maps to more than 10 standards, among them CAPEC, GDPR, IEC 62443, the OWASP Application Security Verification Standard (ASVS), the OWASP API Security Top 10 and the OWASP Top 10 for LLM Applications.

An auditor does not ask about CVE-2025-67635; an auditor asks whether the application keeps its response time under load and releases the resources that it uses. With the chain in hand, the team can show the requirement, the code that satisfies it and the standards that cite it, all from one record.

The PCI DSS page works the other way around, as it lists each v4.0 control with the requirements that cover it.

Exploitation signals on a record and the sources behind them

Each vulnerability record in the public vulnerability database puts its risk signals in one panel, and the panel refreshes as the sources do. The table lists each signal, what it tells you and its value when we traced the record for CVE-2025-67635 (FLAT-CII5B).

Read the signals together, not the base score alone. The base score of 7.5 describes the potential impact in a generic environment. The exploitation signals show a different picture: when we traced the record, EPSS gave a 0.56% probability of exploitation in the next 30 days, and neither KEV nor the exploit sources showed evidence of an attack. The adjusted score of 4.6 is also lower, but its exploit maturity metric takes a default value, so we do not read it as proof that no exploit exists.

VLAI is a model from CIRCL that reads the description of an advisory and predicts a severity level, not a score. For this record it predicts High, with 97% confidence in that level. That is the same level as the original 7.5, while the adjusted score falls in Medium, so the signals do not always agree, and the person who triages should see all of them. We wrote about this gap between base scores and real exploitation in Rethinking vulnerability severity.

Exploitation and severity signals on the record for CVE-2025-67635.

The data comes from more than 15 vulnerability data sources in two groups. Among the advisory providers are CVE.org, OSV, the GitHub Security Advisory Database, Red Hat Security Advisories, the Arch Linux Security Tracker, the GitLab Advisory Database and the NVD. Among the sources of severity and exploitation intelligence are VulnCheck, ENISA, CIRCL, EPSS, CISA KEV, Exploit-DB, Nuclei Templates, PoC-in-GitHub, the Metasploit Framework and GCVE. 

The page lists the license of each source, and each record lists as aliases the IDs that other sources use for the same flaw. Vulnerabilities that our own team discloses appear in Fluid Attacks' security advisories.

Which vulnerability database links a CVE to its fix and its compliance rule?

The security community relies on several public sources, and each one does a specific job. The NVD, run by NIST, scores and describes each CVE. The KEV catalog from CISA lists the CVEs that attackers already use. OSV maps vulnerabilities to open-source package versions, and the GitHub Advisory Database reviews advisories package by package. 

None of them shows how to write the secure code or which compliance control a fix covers, and the Fluid Attacks public vulnerability database takes data from these sources to add that layer:

We checked a real record of each source: the NVD record for Log4Shell, the OSV record for the Log4j advisory, the GitHub advisory for the lodash prototype pollution flaw and the KEV catalog itself.

Use the NVD or OSV to learn that a CVE exists and which version removes it. 

Use the Fluid Attacks Database when you must correct the code and show which control the correction satisfies. Our platform already works this way: each weakness reported by our SAST, SCA and DAST scans or by our pentesters links to its page in the database, and each vulnerable dependency links to its record. 

That is the philosophy behind this vulnerability database: a record is useful when the person who reads it can act on it. To see the chain for your own stack, search a CVE from your last scan in the Fluid Attacks Database.

A finding in Fluid Attacks’ platform links to its record in the database.

Fix options for a transitive dependency, as our platform shows them.

Frequently asked questions

How do I find a record if I only have the CVE ID?

Add the CVE ID to the address of the vulnerabilities section, with the pattern /vul/[CVE ID]/. The page redirects to the record's Fluid Attacks ID: for example, the address for CVE-2026-41242 opens record FLAT-LBEWZ. You can also search by CVE, package name or advisory ID from the search bar at the top of any page.

How does the database link a CVE to a weakness?

Automatically. The database matches the CWE of each advisory against our weakness catalog, and when several weaknesses fit, a language model (embeddings) picks the most similar one. No person reviews each match, so if an occasional mismatch happens, we correct it with a manual patch when we find it. To verify a match, open the record and compare the description of its weakness with the advisory.

How do I check if a package version in my project is affected?

Open the component page, with the pattern /cmp/[ecosystem]/[package]/. For example, the component page for pyjwt in PyPI lists each version of the package with its status and maximum severity. The Components section covers more than 10 ecosystems, among them npm, PyPI, Maven, Go, Cargo and NuGet.

Can I query the database from a script or a CI pipeline?

Yes. The JSON endpoints are public and need no authentication. The endpoint /vul/data.json returns a paginated list, with 100 items per page by default, and /vul/[id]/data.json returns one record. The list accepts filters such as search, severity, ecosystem, epss and fix. The database's llms.txt file lists every endpoint and filter.

What can I do if a record shows no patched version?

A code fix does not depend on a new package version. Open the record's weakness: its fixes show how to remove the flaw from your own code, and its requirements give the control to keep in place while the vendor releases a patch.

How do I use the vulnerability database to prepare evidence for a PCI DSS audit?

Open the PCI DSS page of the database. Its control-requirement table lists each PCI DSS v4.0 control with the requirements that cover it. From each requirement you can open the weaknesses that break it and their fixes. That way, each finding in your report has a control, a cause and a correction.