Pentestas / help

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 two vulnerability databases on a daily Celery Beat schedule:

  • Exploit-DB — sourced from the official GitLab mirror; covers exploits/, shellcodes/, and the papers/ index. Daily diff pulls keep the local copy fresh; full reseed is automatic if the mirror's commit graph diverges.
  • NVD CVE feed — daily delta from the JSON feed, plus weekly full reseed.

Freshness is usually <24 hours. The vulnerability-database card on the dashboard shows the last successful update timestamp and counts for CVEs, Exploit-DB PoCs, and shellcodes.

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.

See also