| Tested on | Kali GNU/Linux Rolling 2026.2 (kali-rolling) |
|---|---|
| Package | curl 8.21.0jq 1.8.1searchsploit (Exploit-DB)msfconsole (Metasploit Framework) |
| Lab environment | Pentest lab |
| Cert prep | CompTIA PenTest+ PT0-003 — vulnerability analysis, exploit selection, and attack-path planning |
| Privilege | Normal user for API lookups, SearchSploit, and Metasploit searches; sudo only if your lab policy requires it for exploitation steps linked from other lessons |
| Scope | Pentester-focused triage after reconnaissance and vulnerability scanning: CVE/CWE/CVSS/EPSS/KEV roles, why raw CVSS sorting fails, a repeatable prioritization checklist, worked Metasploitable 2 example, exploit availability checks, attack-path value, documentation template, and common mistakes. Does not cover enterprise patch SLAs, CVSS v4 math, or full Nessus/OpenVAS deployment. |
Do not sort scanner output by CVSS alone and start at the top. Prioritize confirmed, reachable, and applicable findings first—then use CVSS for severity, EPSS for exploitation probability, CISA KEV for evidence of exploitation in the wild, and ask how much each candidate advances your pentest objective.
Vulnerability prioritization is deciding which findings deserve attention first when a scan produces more candidates than you can validate immediately. In a penetration test, that means prioritizing findings that are real, reachable, exploitable from your current position, and useful to the engagement objective.
After reconnaissance and vulnerability scanning, weigh six questions together:
- Is the finding real and reachable from your test position?
- Is exploitation known or likely in the wild?
- Does the product, version, build, and configuration match the advisory?
- Does credible proof-of-concept code or a framework module exist?
- What access or attack-path value would successful validation provide?
- What operational impact could testing cause under your rules of engagement?
CVSS, EPSS, and CISA KEV answer parts of that picture. None of them replace manual validation.
CVE, CWE, CVSS, EPSS, and KEV: what each one tells you
Scanners and reports throw acronyms together. During a pentest you need the question each identifier answers—not a lecture on CVE history.
| Term | Question it answers | Useful during pentesting? | What it does not tell you |
|---|---|---|---|
| CVE | Which specific vulnerability are we discussing? | Yes — ties scanner rows, advisories, and exploit databases to one ID | Whether your target is affected, reachable, or worth testing |
| CWE | What weakness class is this (XSS, path traversal, buffer overflow)? | Yes — groups similar bugs and suggests validation patterns | Severity, exploitability, or business impact on this host |
| CVSS | How severe are the vulnerability's Base characteristics (impact and exploitability metrics in the vector)? | Yes — quick severity filter and report language | Complete risk to your asset, confirmed exploitation, or attack-path value |
| EPSS | How likely is exploitation activity in the near term (30-day model)? | Yes — separates "theoretical critical" from "actively probed" | Complete risk score, applicability to your version, or guaranteed exploit success |
| CISA KEV | Has CISA confirmed evidence that this CVE has been exploited in the wild? | Yes — strong signal to investigate when the finding applies | That your exact build is vulnerable, or that a public exploit works in your lab |
A CVSS Base score is a severity score, not a complete risk score. CVSS v4.0 is the current specification, although scanners and older CVE records may still expose v3.1 or v2 scores. This article uses the published NVD score for each example and always labels its CVSS version. For pentest prioritization, the important distinction is that the Base score describes severity rather than your target-specific risk or likelihood of exploitation.
EPSS is not a replacement for CVSS and FIRST explicitly warns it is not a complete risk score—do not multiply CVSS × EPSS or treat either as a single "priority number."
EPSS probability vs percentile: the API returns both. Probability is the model's estimated chance of exploitation activity in the next 30 days (0–1). Percentile ranks this CVE's EPSS score against all scored CVEs (also 0–1). A CVE at the 99th percentile has an EPSS score higher than roughly 99% of scored CVEs, but its absolute exploitation probability can still be much lower than 99%—read both fields.
Why the highest CVSS finding is not always your best target
Severity, reachability, exploitability, and attack-path value are independent axes. Four patterns show up on almost every engagement:
| Pattern | Example | Why CVSS misleads |
|---|---|---|
| Critical but unreachable | CVSS 9.8 v3.1 on an admin API bound to 127.0.0.1 |
Scanner severity is high; your test position never sees the port |
| Lower CVSS, confirmed wild exploitation | CVSS 8.1 listed in CISA KEV on an internet-facing service with a working module | KEV and exposure beat a higher CVSS on an internal-only daemon |
| High CVSS, auth you lack | CVSS 7.5 RCE that requires an authenticated admin session |
You have no credentials yet—defer until you gain that role or find another path |
| Medium severity, strong pivot | NVD CVSS v2 6.0 with confirmed version, config, and exploit path | Opens shell access even though the numeric score looks moderate |
On Metasploitable 2, a scanner might flag CVE-2021-44228 (Log4j) at CVSS 10.0 v3.1 with KEV listing and EPSS near 1.0—while the host runs no vulnerable Log4j component. Meanwhile CVE-2007-2447 (Samba username map script) shows only CVSS v2 6.0 on NVD, yet it is reachable on TCP/445 with a reliable Metasploit module when the vulnerable configuration is present. That counterexample is the decision this article teaches.
How to prioritize pentest findings after a vulnerability scan
Use this sequence after every scan export—not instead of reading the advisory.
- Confirm the exposed service or application (port, URL, TLS SNI, virtual host).
- Confirm version, build, patch level, and configuration (banner, package query, credentialed check when allowed).
- Confirm the CVE or plugin finding applies to this instance—not a generic signature match.
- Read the vendor advisory and NVD record for prerequisites and affected ranges.
- Review the CVSS vector string, not only the numeric Base score (network vs local, user interaction, scope).
- Check CISA Known Exploited Vulnerabilities (KEV) for confirmed in-the-wild use.
- Check FIRST EPSS for probability and percentile (note the capture date—scores update daily).
- Search for credible public PoC, Exploit-DB entries, or Metasploit modules.
- Read exploit prerequisites (auth, architecture, default config, race conditions).
- Consider your network position (external, internal VLAN, VPN, jump host).
- Estimate attack-path value (initial access, credentials, privilege, lateral movement).
- Consider disruption (service crash, account lockout, data corruption) against RoE limits.
- Choose validate now, defer, or reject—with a one-line reason in your notes.
Scanner confidence vs exploit confidence — how much to trust the row before you prioritize it:
| Confidence level | Meaning |
|---|---|
| Scanner-only | Plugin or signature claims a possible vulnerability |
| Version confirmed | Product and affected release appear to match |
| Configuration confirmed | Required vulnerable feature or code path exists |
| Exploit applicable | PoC or module prerequisites match your target |
| Validated | Controlled test confirms the finding |
The decision flow below maps that checklist onto a triage path:
Use the signal heuristic below in parallel—not as a formula. RoE, client appetite for noise, and scope always override.
| Signal pattern | Suggested action |
|---|---|
| KEV + exposed + applicable | Investigate immediately; document even if exploitation fails |
| High EPSS probability + credible exploit + relevant target | High priority after applicability checks |
| Critical CVSS but unreachable or not applicable | Validate the false positive, then deprioritize |
| No public exploit + no exposure + low EPSS | Lower priority unless it unlocks a required path |
| Medium severity + strong pivot (creds, trust boundary) | Contextual high priority—note attack-path value |
| Exploit requires auth you do not have | Defer; track for post-credential phase |
Lab target for the worked example
Export the Metasploitable address once per shell before you read the scanner table. These exports last for the current shell only — re-run the block in a new terminal.
export TARGET=192.168.56.127
# Proxmox Group 2 lab: export TARGET=10.10.10.30Worked example: prioritize scanner findings on Metasploitable 2
The table below uses fabricated scanner rows shaped like Nessus or OpenVAS output against $TARGET in the pentest lab. NVD CVSS values and versions are listed per CVE record—do not compare v2 and v3.1 numbers as if they came from one consistent scale. EPSS values were captured on 2026-08-31 from the public API; re-query before you rely on them in a live report.
| # | Host / service | CVE | NVD CVSS | EPSS prob. | EPSS pct. | KEV | Public exploit | Prerequisites | Potential access | Confidence | Priority | Reason |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 1 | 192.168.56.127 / Java (plugin guess) |
CVE-2021-44228 | 10.0 v3.1 | 0.99999 | 1.00 | Yes | Many PoCs | JVM + Log4j 2.x | RCE | Low | Reject | KEV and scores are extreme, but Metasploitable 2 does not expose a vulnerable Log4j app—version/plugin false positive |
| 2 | 192.168.56.127:445 / Samba 3.0.20 |
CVE-2007-2447 | 6.0 v2 | 0.498 | 0.988 | No | Metasploit usermap_script |
Vulnerable Samba release + username map script configuration reachable over SMB | Shell | High | 1 — validate first | Moderate CVSS, but confirmed version and config on 445; module exists; direct shell path |
| 3 | 192.168.56.127:21 / vsFTPd 2.3.4 |
CVE-2011-2523 | 9.8 v3.1 | 0.962 | 0.999 | No | Metasploit backdoor module | Backdoored vsftpd 2.3.4 distribution; trigger via crafted USER |
Shell | High | 2 | Higher severity on paper, but FTP is a secondary path after SMB in this lab ordering; still validate early |
| 4 | 192.168.56.127:3632 / distcc |
CVE-2004-2687 | 9.3 v2 | 0.882 | 0.998 | No | Public distcc exploits | Service enabled | Shell | Medium | 3 | Strong scores; validate after higher-confidence paths unless RoE favors stealth on non-SMB ports |
Why finding #2 beats finding #1: finding #1 wins on CVSS, EPSS, and KEV, yet fails applicability—there is nothing to exploit on that host. Finding #2 carries an NVD CVSS v2 Base score of only 6.0, but you confirmed Samba 3.0.20, the vulnerable username map script configuration is reachable on port 445, and a known module grants shell access. A medium-severity CVE with a working exploit path beats a critical false positive every time.
For exploitation mechanics after you select a module, continue with validate scan results and exploit selection and the Metasploit tutorial.
Read the CVSS vector, not just the number
A CVSS Base score compresses several independent metrics into one number. Two CVEs can share a score of 9.0 and require completely different conditions to exploit. Before you act on a score, read the vector string.
The five metrics that matter most for pentest triage:
| Metric | Values | What it means in practice |
|---|---|---|
| Attack Vector (AV) | N Network / A Adjacent / L Local / P Physical |
N is exploitable remotely without physical access; L requires an existing shell or local session |
| Attack Complexity (AC) | L Low / H High |
H means a race condition, specific non-default configuration, or timing dependency — harder to reliably reproduce |
| Privileges Required (PR) | N None / L Low / H High |
N is unauthenticated; H requires admin credentials you may not yet hold |
| User Interaction (UI) | N None / R Required |
R means someone must click, open a file, or visit a page — usually a separate phishing step |
| Scope (S) | U Unchanged / C Changed |
C means the exploit reaches resources outside the vulnerable component, often privilege escalation or lateral movement |
Consider two vectors at the same numeric score. CVSS:3.1/AV:L/AC:H/PR:H/UI:R/S:U/C:H/I:H/A:H is formally "High" but requires local access, an admin credential, a race condition, and victim interaction — none of that describes a remote unauthenticated scenario. CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H is network, no auth, no user interaction, scope change — that one you stop and verify immediately.
Read the vector string for every finding before you assign priority. NVD and Tenable both display the full string; scanners that only show the numeric score are hiding the most useful part.
Verify exposure and applicability before you prioritize
A finding is only actionable when it applies to the actual component, version, and configuration running on your target. Scanner plugins can guess wrong on any of these.
Check each of the following before treating a finding as confirmed:
| Check | Question to answer |
|---|---|
| Product | Does the target actually run this software — not just an open port that looks like it? |
| Version or build | Does the exact version or package build fall in the affected range stated in the advisory? |
| Service | Is the vulnerable service (HTTP, SMB, FTP, RPC) actually listening on that port? |
| Exposed component | Is the specific vulnerable endpoint, module, or library loaded and reachable? |
| Configuration | Does the vulnerable code path require a specific setting (username map script, anonymous auth, default password)? |
| Authentication requirement | Does exploitation require credentials you currently hold, or a role you have not reached yet? |
| Network position | Can you reach the service from your test position (external, internal VLAN, VPN)? |
| OS or architecture | Does the exploit target a specific OS family or CPU architecture that matches? |
| Mitigation or backport | Has the vendor patched under the same version string — common on RHEL, Debian, and Ubuntu with backported fixes? |
Banner-based fingerprinting misses backported patches and shared-library versions. When your RoE allows credentialed access, a package query (rpm -q, dpkg -l, dpkg-query) gives a more reliable answer than a remote banner check. The validate scan results and exploit selection guide covers the full verification workflow.
Check EPSS probability and percentile
FIRST publishes a free JSON API. Use it for triage notes—not as a sole sort key.
Query one CVE:
curl -s "https://api.first.org/data/v1/epss?cve=CVE-2007-2447"The JSON includes today's epss probability and percentile fields:
{"status":"OK","status-code":200,"version":"1.0","access":"public","total":1,"offset":0,"limit":100,"data":[{"cve":"CVE-2007-2447","epss":"0.497590000","percentile":"0.988110000","date":"2026-08-31"}]}0.49759 means the model estimates roughly a 49.8% chance of exploitation activity in the next 30 days for that CVE globally—not a 49.8% chance your Metasploitable VM will be compromised tomorrow. 0.98811 percentile means this CVE's EPSS score ranks higher than about 98.8% of all scored CVEs that day.
Compare several findings from the same scan in one request:
curl -s "https://api.first.org/data/v1/epss?cve=CVE-2011-2523,CVE-2007-2447,CVE-2004-2687" |
jq -r '.data[] | "\(.cve): prob=\(.epss) percentile=\(.percentile) date=\(.date)"'CVE-2011-2523: prob=0.961840000 percentile=0.998740000 date=2026-08-31
CVE-2007-2447: prob=0.497590000 percentile=0.988110000 date=2026-08-31
CVE-2004-2687: prob=0.881950000 percentile=0.997550000 date=2026-08-31vsFTPd's backdoor CVE shows higher absolute probability than Samba here, which is why EPSS alone would not have told you to pick Samba first—reachability, applicability, and attack-path value broke the tie.
Check CISA KEV for confirmed exploitation
CISA KEV is an authoritative catalog of vulnerabilities with confirmed exploitation in the wild. CISA recommends it as an input into vulnerability prioritization. When a scanner CVE appears in KEV and applies to your target, move it to the top of your review queue.
Absence from KEV does not mean a CVE has never been exploited—only that CISA has not cataloged confirmed in-the-wild use for that ID.
Search the public JSON feed for one CVE:
curl -s "https://www.cisa.gov/sites/default/files/feeds/known_exploited_vulnerabilities.json" |
jq -r '.vulnerabilities[] | select(.cveID=="CVE-2021-44228") | "\(.cveID) \(.vulnerabilityName) added \(.dateAdded)"'CVE-2021-44228 Apache Log4j2 Remote Code Execution Vulnerability added 2021-12-10Log4j belongs in KEV—which is why finding #1 in the worked table demanded extra version validation even though Metasploitable 2 never runs a vulnerable Log4j stack.
Check whether a public exploit actually applies
"Exploit exists" is not "exploit applies." Before you load a module, cross-check product, version, OS, architecture, authentication, and configuration.
SearchSploit (Exploit-DB)
Search Exploit-DB by CVE to see whether public PoC code exists before you trust a scanner plugin title:
searchsploit --cve CVE-2011-2523---------------------------------------------- ---------------------------------
Exploit Title | Path
---------------------------------------------- ---------------------------------
vsftpd 2.3.4 - Backdoor Command Execution | unix/remote/49757.py
vsftpd 2.3.4 - Backdoor Command Execution (Me | unix/remote/17491.rb
---------------------------------------------- ---------------------------------
Shellcodes: No ResultsTwo entries for the same CVE does not mean either will work on your target without the exact backdoored vsftpd 2.3.4 distribution—not every legitimate 2.3.4 build.
Metasploit module search
List framework modules tied to the CVE so you can read rank, check support, and prerequisites in info:
msfconsole -q -x "search cve:2007-2447; exit"Matching Modules
================
# Name Disclosure Date Rank Check Description
- ---- --------------- ---- ----- -----------
0 exploit/multi/samba/usermap_script 2007-05-14 excellent No Samba "username map script" Command ExecutionNote Check: No—Metasploit will not verify the target for you. Banner, version, and configuration confirmation still matter. Full msfconsole workflow lives in the Metasploit tutorial.
Before you run anything, confirm:
- Product name and exact version or build from the vendor advisory
- Vulnerable configuration or code path enabled—not version alone
- Operating system and CPU architecture
- Authentication or session requirements
- Your network position relative to the service
- Reliability, shell type, and side effects (crash, noisy logs)
Prioritize vulnerabilities that advance the attack path
Penetration testing sorts by what validation unlocks next in the scoped objective—not by enterprise asset criticality or patch SLAs.
| Attack-path role | Why a pentester cares |
|---|---|
| Internet-facing initial access | Proves external exposure the client asked about |
| Credential access | Unlocks authenticated findings you could not reach before |
| Local privilege escalation | Turns a low shell into proof of full host compromise |
| Lateral movement | Reaches a new subnet, trust zone, or AD path |
| Domain or cloud privilege | Demonstrates the business impact statement in the SoW |
A medium CVSS misconfiguration that leaks an internal API key can outrank an isolated critical bug on a disconnected lab VLAN if only the former advances you toward the system or objective that matters to the engagement.
Keep this section conceptual in reports: describe the path you would chain, not step-by-step exploitation against production.
Document selected, deferred, and rejected findings
Clients and cert graders want reasoning, not a sorted spreadsheet. Copy this template into your engagement notes or Cervantes project:
Finding: Samba username map script (plugin ID example)
Evidence: TCP/445 open; banner "Samba 3.0.20-Debian"
Target: 192.168.56.127:445
CVE: CVE-2007-2447
CVSS: 6.0 v2 (AV:N/AC:M/Au:S/C:P/I:P/A:P)
EPSS: 0.498 prob / 0.988 percentile (2026-08-31)
KEV: No
Exploit/PoC: Metasploit exploit/multi/samba/usermap_script
Prerequisites: Vulnerable Samba release; username map script config reachable over SMB
Expected result: Remote shell per module
Potential impact: Full host compromise in lab; noisy SMB auth in logs
Decision: Selected — validate first
Reason: Confirmed version and config, reachable from attacker VM, direct shell path despite moderate CVSSOne row per candidate finding—even rejects. "Deferred pending creds" and "rejected false positive" are valuable audit trail.
Common vulnerability prioritization mistakes
| Mistake | What goes wrong | Better habit |
|---|---|---|
| Sorting only by CVSS | You chase critical bugs on dead ports or wrong versions | Confirm reachability and applicability first |
| Treating EPSS as severity | High EPSS does not mean "critical impact" | Pair EPSS with KEV, advisories, and exposure |
| Confusing percentile with probability | 99th percentile ≠ 99% chance on your host | Read both EPSS fields; cite the API date |
| Multiplying CVSS × EPSS | Implies a risk score FIRST does not endorse | Use qualitative checklist and documented reasoning |
| Trusting scanner version strings | Banner spoofing and incomplete plugins create false positives | Verify with manual enumeration |
| Assuming Exploit-DB match = success | PoCs target specific builds and configs | Read prerequisites; test in lab |
| Ignoring configuration prerequisites | Version match without vulnerable feature enabled | Confirm config, not only the version string |
| Ignoring attack-path value | You prove a critical bug that does not move the objective | Ask what access the finding unlocks |
| Using stale EPSS exports | Scores change daily | Re-query or timestamp screenshots |
| Skipping KEV when CVE matches | You miss confirmed wild exploitation signal | Check KEV after applicability, before deep exploit work |
Summary
Vulnerability prioritization for penetration testing starts where scanning ends: you have a list of candidate weaknesses, and you must decide which ones deserve validation time in an authorized engagement. CVE identifies the specific vulnerability; CWE describes the underlying weakness class; CVSS Base describes severity characteristics; EPSS estimates near-term exploitation activity; CISA KEV flags confirmed in-the-wild use. None of those replace confirming that the service is reachable, the version and configuration match, and a credible exploit fits your position.
The highest CVSS row is often not the best next test. A Log4j finding with perfect scores fails when the host does not run Log4j, while a CVSS v2 6.0 Samba issue on an open port with a confirmed configuration and known module delivers the shell you need. Pair FIRST EPSS lookups, KEV checks, SearchSploit, and Metasploit searches with a written reason for select, defer, or reject—then continue into exploit selection and hands-on validation on Metasploitable 2.
References
- FIRST EPSS API and documentation
- CISA Known Exploited Vulnerabilities Catalog
- FIRST — CVSS v4.0 specification
- NVD — CVE-2007-2447
- NVD — CVE-2011-2523
- NVD — CVE-2004-2687
- NVD — CVE-2021-44228
Frequently Asked Questions
Is EPSS better than CVSS?
They measure different things. CVSS Base describes severity characteristics of a vulnerability. EPSS estimates how likely exploitation activity is in the near term across the internet. Use both during triage, plus KEV, reachability, and applicability—do not treat either as a complete risk score.
Does a high CVSS mean a vulnerability is easy to exploit?
A high CVSS score does not guarantee that an exploit works against your target. The affected feature may be disabled, the scanner may have identified the wrong version, authentication or user interaction may be required, or network controls may make the service unreachable from your test position. Always read the vector string and the advisory prerequisites.
What is a good EPSS score?
There is no universal "high EPSS" cutoff. Compare both probability and percentile, then choose a threshold appropriate to how many findings you can realistically review. FIRST discusses threshold selection as a tradeoff rather than a single magic value—a probability of 0.5 means better-than-even odds of near-term exploitation activity globally, not on your asset.
Is CISA KEV more important than EPSS?
KEV means CISA has cataloged confirmed in-the-wild exploitation—strong signal to investigate when the finding applies to your target. EPSS is a probabilistic forecast that updates daily. KEV is narrower and more definitive; EPSS covers more CVEs with statistical estimates. Check both.
Can a low-CVSS vulnerability still be important in a pentest?
Yes. Misconfigurations, information disclosure, and weak credentials may score modestly on CVSS yet unlock credentials, lateral movement, or a required attack path. Attack-path value often matters more than the Base score alone.
