Exploitable Vulnerabilities Database
The local CVE database with real exploitation evidence, and everything that queries it.
A local database of CVEs that carry real exploitation evidence, queried entirely inside the deployment. No external lookup, no data leaving the installation.
The shipped database holds close to 130,000 CVEs, and every one of them carries at least one piece of exploitation evidence. A CVE with nothing behind it but a severity score is not in here. The feed ships with the image and grows with each release — the exact count for a given build is the total on the Vuln DB list.
Reach it through the Vuln DB menu.
What counts as evidence
Every entry carries evidence rather than a severity label. A CVE detail page reports which of these apply:
| Signal | Meaning |
|---|---|
| Exploited in the wild | Listed as known exploited — the strongest signal available. |
| Public exploit available | A working exploit has been published. |
| Proof of concept published | PoC code exists, though not necessarily a weaponised exploit. |
| Predicted exploitation (EPSS) | A high EPSS score, shown with its percentile. |
| No exploitation evidence | Present in the database, but none of the above apply. |
Proof-of-concept code is by far the most common signal, and known-exploited the rarest — which is why the badge matters more than the count. Approximate shares of the present feed:
- ~81,000 proof of concept published
- ~25,000 public exploit available
- ~18,000 predicted exploitation (EPSS)
- ~5,200 exploited in the wild
Each entry also carries the vulnerability name, description, solution, and the exploit reference URLs where they exist.
A CVSS label alone is not evidence. The point of this database is the distinction between "scored severe" and "someone has actually exploited this".
What queries it
The database is not just a lookup screen — it gates several automated decisions:
| Consumer | How it uses the database |
|---|---|
| Dependency reachability | The second gate: a CVE must appear here before a finding is worth an agent loop. |
| Enriched scan reports | The "Exploit" column in the Trivy, Nessus, OpenVAS and Nuclei spreadsheets comes from the same presence check. |
| AI Pentest exploit research | The agent looks a product and version up here, then fetches the referenced exploit to build a proof of concept. |
| Manual triage | Full-text search across every field, from the Vuln DB menu. |
Searching by product
Affected versions live in free text, so product lookups match the product name where it sits next to a version rather than anywhere a product happens to be mentioned. Results are assessed against the version you supply and ranked likely-vulnerable first — a version at or below the highest affected version mentioned near the name is treated as likely vulnerable.
This matters when triaging an infrastructure finding: searching for the exact product and version tells you whether the CVE the scanner reported has a published exploit, which is usually the difference between this week and next quarter.
Related
Checking for exploitable vulnerabilities
Using the exploitable-CVE database to tell a real risk from a severity label.
Dependency reachability
Four gates that cut a dependency scan down to the advisories the application can actually reach.
AI Pentest
An agent that plans an engagement, runs the tools, and proves what it finds.
Last reviewed 2026-08-16