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 your deployment. No external lookup, no data leaving the installation.
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. |
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 your 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 your code can actually reach.
AI Pentest
An agent that plans an engagement, runs the tools, and proves what it finds.
Last reviewed 2026-08-16