Verify Vulnerability Exploitability: An Evidence Guide

To verify vulnerability exploitability, stop treating a version match as proof. The real question is whether the affected condition exists, runs, accepts attacker input, and can produce the stated impact on this asset.

A scanner is right to be cautious. It often sees a product name and version but not a backported patch, disabled feature, local firewall, required privilege, or unused code path. The scanner should create a finding. It should not make the final risk decision.

Verification is not a hunt for reasons to close tickets. It is a disciplined attempt to prove or disprove each condition in the attack path. If the evidence stops halfway, the verdict is unknown. That is a useful answer.

What does it mean to verify vulnerability exploitability?

Exploitability has several meanings that teams often mix together. CVSS describes the characteristics and potential impact of a vulnerability. EPSS estimates whether exploitation activity will be observed in the wild. CISA KEV records evidence that exploitation has already occurred. Local verification asks a different question: can the known attack conditions work against a specific deployed instance?

The distinction matters because each signal answers a different decision. The CISA Known Exploited Vulnerabilities catalog is a living list based on evidence of exploitation in the wild. An entry proves that a vulnerability has been exploited somewhere. It does not prove that the vulnerable feature is enabled on your server.

FIRST reported that its EPSS data release for July 20, 2026 scored 349,944 CVEs, including 453 newly scored records that day. An EPSS score is a daily probability of exploitation activity in the next 30 days. It is not a probe of your network, process list, or application path.

Which evidence should you collect first?

Start with the cheapest evidence that can change the decision. Do not launch an exploit when package identity already shows that a vendor backport fixed the issue. Do not close a finding because a port scan failed from one network segment. Move up the evidence ladder only when the prior step leaves a material question open.

1. Confirm identity. Match the advisory to the exact product, edition, package source, build, architecture, and patch state. Distribution vendors often backport a fix without changing the upstream version in the way a generic scanner expects.
2. Confirm runtime state. Check whether the affected service, driver, module, feature, or library is loaded. Installed but dormant code may still deserve a patch, but it does not support the same immediate claim as an active service.
3. Confirm reachability. Identify the real entry point, listening address, firewall path, authentication boundary, and caller. Test from the attacker position named in the advisory.
4. Confirm required conditions. Record needed privileges, configuration flags, user action, timing, feature state, and code path. One missing condition can block the published exploit while another path remains possible.
5. Confirm impact safely. Use a vendor check, non destructive probe, staging reproduction, control test, or approved penetration test. Production exploitation is the last option, not the definition of good verification.

This ladder adds the local evidence that the CISA KEV prioritization workflow cannot supply. KEV should raise urgency. Local evidence decides the owner, action, and safe deadline.

How can endpoint evidence verify the attack path?

Suppose an advisory says a service listening on TCP 8443 is affected. The scanner matched an installed version, but it did not show whether the service runs or where it listens. On Windows, the official Get-NetTCPConnection documentation supports filtering by state and local port. This read only check ties the listener to its owning process:

$port = 8443
$listeners = Get-NetTCPConnection -State Listen -LocalPort $port
$listeners | Select-Object LocalAddress, LocalPort, OwningProcess
$listeners | ForEach-Object { Get-Process -Id $_.OwningProcess }

A result bound to 127.0.0.1 supports a different reachability claim than a result bound to 0.0.0.0. Neither result closes the case alone. Check firewall policy, reverse proxies, tunnels, container mappings, and access from the relevant network position. Then confirm the process build against the vendor advisory.

Capture the command, host identifier, time, output hash or attachment, and reviewer. A pasted screenshot with no asset or timestamp is weak evidence. A repeatable command with a recorded result can be checked after the next deployment.

How do you handle backports and version ambiguity?

Version comparison is where many verification records go wrong. An upstream project may publish a fixed version, while an operating system vendor applies the fix to an older package and keeps much of the original version string. A scanner that compares only upstream numbers may report the patched package. The opposite failure happens when inventory records an application bundle but misses a second copy installed by a user or container image.

Use a source order. Start with the advisory from the vendor that supplied the installed package. Match its package release, build identifier, and platform. Then compare the upstream advisory and CVE record. Finally, reconcile the scanner evidence. If the sources disagree, keep the verdict unknown and assign the conflict. Do not choose the source that creates the smallest queue.

Consider a Linux package labeled 2.4.57-8.el9_4.1. The upstream number alone is 2.4.57, but the distribution release after the dash can identify vendor patches and rebuilds. A reviewer who discards that suffix may call a fixed host vulnerable. A reviewer who trusts it without reading the distribution advisory may make the opposite error. Capture both the full installed string and the exact advisory rule used to interpret it.

Also check scope. Package evidence from the host does not settle a container, appliance, statically linked binary, or application supplied library. Ask where the vulnerable code came from, where it runs, and which update channel owns it. Identity is the first rung because every later test inherits its mistakes.

Which exploitability verdicts are defensible?

Binary labels create false confidence. Use a small verdict set that states what the evidence supports and what it does not.

• Confirmed exposure: affected code, reachability, required conditions, and safe proof align.
• Exposure possible: the affected condition exists, but one or more attack conditions remain unknown.
• Mitigated: the condition exists, but a tested control currently blocks the required path or impact.
• Not affected: trusted evidence disproves product identity, affected build, feature state, or required condition.
• Unknown: the team lacks current evidence. Unknown belongs in the queue, not in an exception list.

Avoid the permanent label “not exploitable.” A firewall rule can change. A dormant feature can be enabled. A new exploit can remove a prerequisite. Write “not reachable from the internet as tested on August 4, 2026” and name the event that forces review.

Our guide to why vulnerability scanners produce false positives explains the detection limits behind many weak matches. The fix is better evidence, not a blanket suppression.

Where should verification effort go first?

Verification has a cost, so spend it where a changed verdict changes action. Imagine 1,200 new findings and an eight minute manual review for each. That is 9,600 minutes, or 160 analyst hours. Four analysts would each lose a full 40 hour week before one fix starts.

Now apply cheap gates first. Suppose identity and patch evidence resolve 720 findings, runtime state resolves 240, and reachability evidence resolves another 150. Ninety findings remain for deeper review. At 30 minutes each, that is 45 hours. The team spends more time per hard case but 115 fewer hours overall. The numbers are an example. The operating point is real: automate common evidence, preserve unknowns, and reserve active testing for the short list where the answer changes a decision.

What changed in exploitability assessment in 2026?

On January 6, 2026, FIRST published its CVSS v4.0 Consumer Implementation Guide. It tells vulnerability teams to enrich Base scores with threat and environmental evidence. The guide says only three to five percent of CVEs have known exploits, while its maturity section cites sources placing functioning exploits below six percent.

The worked examples show why local conditions matter. Changing attack requirements in one example moves the score from 9.3 to 7.7. Adding exploit maturity and local conditions moves another vector from 9.3 to 6.4. Those numbers are not permission to ignore the flaw. They show that the standards body now gives consumers a concrete way to document what the generic Base score leaves out.

Many ranking articles still stop at “run a proof of concept” or “check if a service is exposed.” That advice skips safety, evidence age, incomplete tests, and the difference between a blocked published exploit and no possible exploit. A useful process records the claim boundary as carefully as the result.

When is active exploit testing justified?

Use active testing when passive evidence cannot settle a high consequence decision, the method is authorized, and the target can tolerate failure. Prefer a production equivalent environment. Define the source address, payload, expected system change, stop condition, monitoring owner, rollback, and evidence handling before the test.

A failed exploit attempt is not proof of safety. The module may target a different build, need credentials, depend on timing, or lack a step used by current attackers. Record exactly what failed. Keep the verdict at mitigated, possible, or unknown unless the broader evidence supports something stronger.

Use the process in alert tuning with coverage tests for validation changes too. A new firewall exception, feature toggle, or network route can invalidate yesterday's evidence without changing the CVE.

What belongs in an exploitability evidence record?

Store the CVE and affected instance, scanner claim, vendor advisory, exact build, runtime state, entry point, required conditions, threat signals, tested controls, test method, result, missing evidence, verdict, owner, date, and review trigger. Attach raw evidence where policy allows. Redact secrets and exploit payloads from broad tickets.

Artemes AI uses deep endpoint context with AI driven analysis to help assemble a reviewable case around a finding. Practitioner review still owns the verdict. A model can organize evidence and point out missing fields, but it should not turn an untested assumption into “not affected.”

Frequently asked questions

Does a high EPSS score prove a vulnerability is exploitable on my asset?

No. EPSS estimates the chance of exploitation activity in the wild during the next 30 days. It does not inspect your installed build, feature state, network path, privileges, or controls. Use it to order verification work.

Does a CISA KEV entry remove the need for local verification?

KEV status proves exploitation has occurred and should raise urgency, but it does not remove local review. Verification still confirms affected instances, action ownership, available mitigations, and whether an emergency path exists while patching proceeds.

Can a blocked proof of concept justify risk acceptance?

Not by itself. Record why it failed, what paths were not tested, how long the blocking condition will hold, and what forces review. A failed test can support a bounded mitigation claim, not a permanent safety claim.

How often should exploitability evidence be refreshed?

Refresh it after configuration, network, software, identity, or control changes. Also review when exploit code, KEV status, or vendor guidance changes. High consequence exceptions need a fixed expiry even if nothing changes.

Executive takeaway

Do not ask analysts to “prove it is exploitable” with no standard. Give them the evidence ladder and five bounded verdicts. Automate identity, runtime, and reachability checks. Send only the unresolved high consequence cases to active testing. Every closure should state what was tested, when it was true, what remains unknown, and what event reopens the finding. That is how verification cuts noise without manufacturing certainty.