Exploit Evidence Validation

Summary

Exploit evidence is information supporting a claim about exploit theory, code, attempts, successful exploitation, or compromise. It must remain separate from vulnerability severity. CVSS does not prove exploitation; EPSS is a probability signal, not proof; and KEV inclusion is known exploitation evidence, not proof of local compromise. Validate evidence by claim, provenance, reproducibility, scope, and local relevance.

Why it matters

A proof-of-concept claim is not the same as reliable exploitation. Public exploit code is not the same as observed exploitation, and a successful lab demonstration is not proof of broad weaponization. Scanning is not proof of successful exploitation. Public claims can change priority, but observed exploitation elsewhere does not automatically establish local applicability or compromise.

When to use this guidance

Use this when reviewing vendor advisories, vulnerability descriptions, proof-of-concept claims, exploit repositories, technical demonstrations, scanning or honeypot telemetry, malware or incident reports, government advisories, CISA KEV, national CERT reporting, research, social-media claims, and internal IDS, IPS, EDR, SIEM, WAF, DNS, proxy, authentication, or endpoint telemetry.

Prerequisites

Define the exact exploit claim and preserve its original source, record ID, URL, publication date, modification date, and retrieval context. Confirm the affected product and version before connecting public exploit evidence to a local asset. Do not paste secrets, customer data, malware, exploit code, credentials, or raw incident evidence into public tools.

Core concepts

Vulnerability exists is distinct from an exploit theory, proof-of-concept claim, reproducible proof of concept, functional demonstration, weaponization, or observed exploitation.
Exploit reliability is distinct from weaponization. Code can work in a controlled environment without being broadly usable.
Active exploitation reported is distinct from successful local exploitation. Local compromise confirmed needs validated local investigation evidence.
Local exposure, local applicability, and exploit evidence must be assessed separately. No matching local telemetry is not proof of no compromise when collection gaps exist.

Exploit-evidence types

Evidence can include a vendor advisory, proof-of-concept claim, reproducible technical research, exploit module or repository, controlled exploit demonstration, scanning telemetry, honeypot telemetry, malware sample, incident or threat-intelligence report, government or CERT advisory, vendor- or researcher-confirmed exploitation, social-media reporting, internal detection telemetry, and incident-response evidence. Each source can support only the claim it actually observes.

Exploit-evidence states

Use descriptive states: no evidence located, theoretical, claimed, proof-of-concept available, reproducible proof-of-concept, functional exploit demonstrated, weaponization suspected, active exploitation reported, active exploitation corroborated, cataloged known exploitation, local exploitation suspected, local exploitation confirmed, conflicting, stale, and unknown. These describe available evidence, not a universal risk score or proof of compromise. Different sources may support different states, and corrections can move a conclusion backward.

Exploit prerequisites and scope

Exploitability can depend on exact product, version, edition, architecture, platform, feature state, configuration, authentication, privilege, network reachability, user interaction, chained vulnerabilities, race conditions, timing, memory protections, deployment model, cloud service configuration, third-party components, and compensating controls. Code working against one environment does not prove applicability to another.

Evidence quality guidance

Evidence	Typical support	Limitations
Social-media claim	Lead only unless independently verified	May lack provenance, technical detail, or scope.
Public repository	Proof-of-concept claim or code availability	May be incomplete, nonfunctional, malicious, or environment-specific.
Reproducible technical research	Functional proof-of-concept evidence	Controlled conditions may not represent broad exploitation.
Scanning telemetry	Interest or exploit attempts	Does not prove successful exploitation.
Incident report with technical evidence	Observed exploitation	Scope and attribution can remain limited.
CISA KEV	Cataloged known exploitation	Not proof of local compromise or exhaustive global coverage.
Internal telemetry or forensics	Local attempts, exploitation, or compromise evidence	Depends on collection, detection, validation, and scope.

This table is guidance, not a universal hierarchy. Preserve source provenance and do not infer more than the evidence supports.

Practical validation workflow

Define the exact exploit claim.
Identify and preserve the original source and dates.
Determine whether the claim concerns code, attempts, successful exploitation, or compromise.
Validate affected product and version scope.
Review technical details, prerequisites, and environment assumptions.
Assess reproducibility and whether evidence is direct observation or inference.
Seek independent corroboration and preserve conflicts.
Separate internet scanning from successful exploitation.
Review KEV and other catalogs without treating absence as proof of safety.
Review local telemetry, its coverage, and collection gaps.
Assign a bounded exploit-evidence state, uncertainty, and next validation step.
Reassess when authoritative evidence or local context changes.

Distinguishing scanning, attempts, exploitation, and compromise

Scanning can show interest, reconnaissance, or an attempted path; it does not prove a target accepted an exploit. Detection of an attempt may support investigation, but successful exploitation needs evidence of the expected outcome. Local compromise requires validated investigation evidence and careful scope. Do not turn an inferred chain into an observed event.

Local telemetry and coverage gaps

Review relevant IDS, IPS, EDR, SIEM, WAF, DNS, proxy, authentication, and endpoint sources alongside asset inventory and local exposure. State the time range, collection coverage, detection assumptions, and missing data. No matching alerts do not prove no compromise when endpoint, WAF, logging, or retention coverage is incomplete.

Evidence to collect

Record the claim; CVE or issue; affected product and version; original exploit source; URL and record ID; publication and modification dates; code or demonstration location; prerequisites; environment; reproducibility; success and failure conditions; direct versus inferred evidence; corroborating and conflicting sources; KEV and other catalog state; scanning and exploitation evidence; local exposure, indicators, telemetry, and coverage; exploit-evidence state; confidence; unresolved questions; next validation step; and reassessment trigger.

Common mistakes

Do not treat CVSS or EPSS as exploit proof, KEV as proof of local compromise, absence from KEV as proof of no exploitation, a repository as proof code works, a proof of concept as weaponized exploitation, scanning as successful exploitation, social-media repetition as source validation, no alerts as proof of no compromise, or exploit evidence as a substitute for local applicability. Preserve dates, prerequisites, conflicts, and telemetry gaps.

Worked example

A fictional vulnerability has a high CVSS score and a vendor advisory confirming specified affected versions. An unverified repository claims proof-of-concept code. A researcher demonstrates the issue in a controlled lab, while one organization reports scanning and several social-media posts claim active exploitation. There is no initial government catalog inclusion. Later, an authoritative incident report confirms exploitation in a limited product configuration. One local deployment is confirmed affected and internet-facing; another has a configuration that removes the vulnerable feature. No internal alerts match, but WAF and endpoint coverage are incomplete. The vulnerability and reproducible proof-of-concept evidence are confirmed for the stated scope. Scanning does not prove successful exploitation; early active-exploitation claims were unverified, while later evidence supports limited-configuration exploitation. Earlier catalog absence did not prove no exploitation. The two local deployments have different applicability and exposure, and further local validation remains required.

Writing a bounded conclusion

Use: Claim evaluated; Affected scope; Available evidence; Exploit-evidence state; Corroboration; Conflicts; Local applicability; Local telemetry; Coverage limitations; Confidence; Next action; and Reassessment trigger. This keeps observation, inference, proof-of-concept, exploit attempt, successful exploitation, and local compromise separate.

Reassessment triggers

Reassess when source content changes, code becomes reproducible or is retracted, a vendor updates scope, a catalog changes, an incident report appears, an asset or configuration changes, telemetry coverage improves, or a local indicator is observed.

Handling exploit code safely

Do not execute unknown exploit code in production or test systems without authorization. Use isolated approved test environments, review code provenance, treat repositories and binaries as potentially malicious, preserve legal and change-control requirements, use vendor-supported validation where available, and prefer non-destructive validation. This article provides no executable exploit steps, weaponization guidance, or code.

Limitations

Public reporting can be incomplete; repositories can change or disappear; code can be environment-specific; controlled demonstrations may not represent real-world reliability; catalog inclusion can lag or vary; and internal telemetry can have coverage gaps. Absence of evidence does not prove absence. This guidance does not replace incident response, legal approval, vendor guidance, or authorized security testing procedures.