Exploit-DB matches

For every finding that looks version-specific (detected software + version) or CVE-adjacent, Pentestas pulls up to 5 ranked Exploit-DB candidates. The goal: "what public exploit should I read first if I want to understand the blast radius of this finding?"

Ranking inputs

Three match types, combined:

CVE-exact

Finding claims CVE-YYYY-NNNNN; an Exploit-DB entry lists the same CVE. Highest confidence. If the finding is real, the EDB entry is a drop-in PoC.

CPE + version

Finding detected product + version. EDB entry's platform + title matches the product. EDB date_published vs. the version's release history is used to weed out exploits that came out before the version existed.

Product keyword

Finding mentions a product (WordPress, phpMyAdmin, Confluence, …) without a CVE. Keyword search against EDB title. Lowest confidence — useful as a research pointer.

Ranking outputs

Each candidate carries:

edb_id — numeric ID. Click to open exploit-db.com/exploits/<id>.
confidence — 0.0–1.0, combining match type + age-decay + platform alignment + verified-flag.
match_type — cve-exact / cpe-version / product-keyword.
rationale — short human-readable "why this ranks where it does".
type — local, remote, webapps, dos, shellcode, papers.
platform — Linux, Windows, PHP, etc.
verified — EDB's own verified flag (they confirmed the exploit works).
date_published — public release.
cves — associated CVE list.

Reading the rank list

Sort is descending by confidence. The top candidate is usually the one to read first. If the top two are cve-exact / verified:true / date_published within 6 months of your version's release, you probably have a practical exploit available.

How Pentestas uses the match internally

The AI narrative layer reads the top matches and weaves them into the impact paragraph ("CVE-2024-NNNN against Apache 2.4.49 is public; weaponised exploits exist").
Executive reports include the top 3 in the per-finding detail page.
The matcher results are stored in the findings.exploit_candidates JSONB column; you can query them via the API for your own tooling.

Updating the database

Pentestas mirrors Exploit-DB nightly via a scheduled Celery task. Freshness is usually <24 hours. Enterprise customers can enable an even-tighter hourly refresh.

Pitfalls

Matching on version alone is noisy. The confidence score demotes keyword-only matches, but you still need to read the rationale before acting.
An EDB entry is not proof of vulnerability. It's proof that someone at some point had a working exploit against a version that may or may not match your config.
Not all CVEs have EDB entries. Especially newer CVEs, or vendor-disclosure-only issues. Absence of an EDB hit doesn't mean you're safe.