CISA KEV can tell you something extremely important about a vulnerability: reliable evidence exists that attackers have exploited it in the wild. What it cannot tell you by itself is whether the vulnerability exists on your system, whether attackers could reach it, whether anyone attempted exploitation against your asset, or whether your system was successfully compromised.
Those are separate evidence states — and confusing them can lead to two opposite mistakes: underreacting because a patch is now installed, or overreacting by treating every KEV-listed CVE as proof of a breach.
Direct answer
Does CISA KEV mean your system was hacked?
No. A vulnerability’s presence in CISA’s Known Exploited Vulnerabilities Catalog means CISA has evidence that exploitation has occurred in the wild.
To determine what happened to your system, you still need to establish whether an affected version was installed, whether the vulnerable attack path was reachable, whether your asset was exposed during the relevant period and whether local evidence shows attempted or successful exploitation.
Important 2026 change
Patching and compromise checking are separate tasks
CISA’s 2026 BOD 26-04 introduced risk-based federal remediation requirements using factors including asset exposure, KEV status, exploit automation and post-exploitation impact.
In designated scenarios, CISA also requires agencies to check whether an adversary compromised the asset before the patch was applied.
KEV confirmed
Exploited in the wild
There is evidence the vulnerability has been exploited against real targets somewhere.
Local exposure
Your asset may be reachable
Your environment runs the affected condition and the attack prerequisites may be present.
Local exploitation
Attack reached your asset
Telemetry or other evidence indicates exploitation was attempted or the vulnerable path was triggered locally.
Compromise
Successful security impact
Unauthorized execution, access, persistence, data access or another post-exploitation effect occurred on your environment.
The four states above must not be collapsed into one. KEV confirms exploitation at the vulnerability level. Local compromise is an asset-level conclusion that requires local evidence.
In this guide
- What CISA KEV actually proves
- What KEV does not prove
- The full evidence chain
- Check whether you are affected
- Check whether attackers could reach it
- Build the exposure window
- Attempted vs successful exploitation
- When patching may not be enough
- Check for compromise evidence
- CVSS vs EPSS vs KEV
- Response workflow
- Worked example
- Verification boundaries
- Limitations
- FAQs
What CISA KEV actually proves
CISA maintains the Known Exploited Vulnerabilities Catalog to identify vulnerabilities for which there is evidence of exploitation in the wild. CISA continues adding CVEs when they meet its criteria, and organisations can use the catalog to prioritise remediation.
The practical meaning is:
KEV answers: “Has this vulnerability crossed from theoretical vulnerability into observed real-world exploitation?”
That is a major escalation in threat evidence. A proof-of-concept exploit existing online is not the same as evidence that attackers have actually used the flaw in the wild.
If the CVE is relevant to a product you operate, KEV should therefore materially increase remediation priority.
You can check the current catalog directly on the CISA Known Exploited Vulnerabilities Catalog.
What a KEV listing does not prove
KEV does establish
- the vulnerability has a CVE;
- CISA has evidence of exploitation;
- the vulnerability has crossed into real-world attacker use;
- remediation deserves elevated priority.
KEV does not automatically establish
- your organisation uses the product;
- your installed version is affected;
- the vulnerable feature is enabled;
- the attack path is reachable;
- your asset was targeted;
- an exploit succeeded locally;
- the system was compromised.
This distinction is the foundation of a defensible response.
The evidence chain from CVE to compromise
Stage 1 — vulnerability applicability
Stage 2 — attack opportunity
Stage 3 — exploitation evidence
Editorial interpretation: KEV belongs in the middle of the investigation. It changes what you know about attacker behaviour globally, but it does not replace the asset-level evidence needed below it.
Step 1: confirm that your system is actually affected
Do not start by searching logs for attackers before confirming that the vulnerability could exist on your asset.
Product identity
Confirm the exact product, edition, appliance, module or library named by the advisory.
Version range
Compare your installed build with the vendor’s affected and fixed version ranges.
Configuration
Check whether the vulnerable component or feature is enabled and whether any required attack condition exists.
A scanner finding, package inventory entry or product name may still require validation. Some vulnerabilities apply only to a particular configuration, feature, deployment mode or build.
Do not use KEV as an asset inventory. KEV tells you which vulnerabilities CISA has evidence attackers exploit. Your own inventory tells you whether those vulnerabilities are relevant to your estate.
Step 2: determine whether attackers could reach the vulnerable path
NCSC’s active-exploitation guidance highlights exposure as a key discriminator after an organisation confirms that it owns an affected system.
Questions to resolve can include:
- Was the vulnerable service internet-facing?
- Could an attacker reach it through a public hostname or IP?
- Was access restricted by VPN, firewall or allow-list?
- Was authentication required?
- Did exploitation require an existing low-privilege account?
- Was the vulnerable endpoint or feature actually enabled?
- Could the vulnerable component be reached from another compromised internal system?
Lower local exposure
- affected software is not deployed;
- fixed version was already installed;
- vulnerable component is disabled;
- required attack path is inaccessible.
Higher local exposure
- affected version is confirmed;
- service is publicly reachable;
- known exploit path is enabled;
- little or no prerequisite access is required.
These examples are triage factors, not universal proof of safety or compromise. The exact exploit conditions must come from the vendor and vulnerability-specific guidance.
Step 3: build the exposure window
This is one of the most useful checks after a KEV alert.
You need to reconstruct when the vulnerable condition existed on your asset and when it ended.
Exposure-window timeline
The important question is not only:
“Are we patched now?”
It is also:
“Was this asset exposed while attackers were exploiting the vulnerability?”
If the answer is yes, the patch closes the vulnerable condition going forward, but the historical period may still require review.
Attempted exploitation is not the same as successful compromise
This distinction matters even when security telemetry says “exploit detected.”
FIRST’s EPSS methodology explicitly notes that its exploitation-activity sources can include honeypot attacks and traffic blocked by intrusion-prevention systems. Those observations demonstrate attacker activity, but they do not necessarily represent successful compromise.
Do not collapse these states
Example: an IPS blocking a known exploit payload is useful evidence that an attacker targeted the vulnerability. It is not, by itself, proof that the exploit succeeded.
When patching may not be enough
A patch fixes or mitigates the vulnerable condition. It does not automatically remove an attacker who exploited the vulnerability before remediation.
CISA’s BOD 26-04, released in June 2026 for US federal civilian agencies, explicitly separates rapid remediation from pre-patch compromise assessment in designated scenarios.
NCSC similarly advises organisations responding to critical actively exploited vulnerabilities to assess compromise while remediation is being applied rather than waiting for patching to finish before beginning the investigation.
Patch and verify
This may be the primary workflow when evidence establishes an affected vulnerability but local exposure is limited and vulnerability-specific guidance does not indicate further compromise assessment is required.
Patch plus investigate
This becomes more important when an affected asset was reachable during active exploitation, the flaw has high post-exploitation impact, or vendor/CISA guidance tells defenders to look for historical compromise.
Do not turn this into “every KEV vulnerability means assume breach.” Investigation depth should follow the vulnerability, exposure, asset importance, observed evidence and authoritative incident guidance.
Step 4: check for evidence of local compromise
There is no universal KEV log query or universal list of indicators of compromise.
The investigation should begin with the vendor advisory, CISA material and credible vulnerability-specific threat research. Depending on the CVE and platform, relevant evidence can include:
Access evidence
- authentication events;
- web access logs;
- VPN or gateway logs;
- unexpected source addresses.
Execution evidence
- unexpected processes;
- suspicious child processes;
- command execution;
- new services or scheduled tasks.
Post-exploitation evidence
- new accounts;
- persistence;
- configuration changes;
- unexpected outbound traffic;
- credential or data access.
The time range matters. If a system was patched today, preserve and review evidence covering the period when the vulnerable version was exposed.
Do not restrict analysis to evidence generated after the patch was installed.
CVSS vs EPSS vs CISA KEV vs local evidence
These signals answer different questions and should not be used interchangeably.
| Signal | Main question | What it does not tell you alone |
|---|---|---|
| CVSS | How severe are the vulnerability’s technical characteristics? | Whether attackers are exploiting it or whether your asset is compromised |
| EPSS | What is the estimated probability of exploitation activity being observed in the next 30 days? | Whether the vulnerability affects your environment or whether your system was hacked |
| CISA KEV | Is there evidence that this CVE has already been exploited in the wild? | Whether your particular asset was successfully exploited |
| Asset evidence | Do you actually run the affected product/version and attack path? | Whether an attacker used it |
| Incident evidence | Was your asset targeted, exploited or compromised? | The global prevalence of exploitation |
FIRST’s CVSS guidance explicitly says the CVSS Base Score measures severity rather than risk. FIRST also states that EPSS is a population-level exploitation forecast and does not know whether a vulnerability affects a particular organisation’s environment.
Best combined reading: CVSS helps describe technical severity; EPSS estimates future exploitation activity; KEV tells you exploitation has already been observed; your asset and incident evidence tell you what that means locally.
A practical CISA KEV response workflow
1
Confirm the CVE
Use the exact KEV entry and vendor advisory. Do not act on a screenshot or headline alone.
2
Map affected assets
Find the exact product, version, feature and deployment mode across your estate.
3
Determine reachability
Check whether attackers could reach the vulnerable attack path.
4
Preserve evidence
Retain relevant logs and telemetry covering the vulnerable exposure window.
5
Patch or mitigate
Apply the vendor/CISA remediation without unnecessarily delaying it for investigation.
6
Assess compromise
Use vulnerability-specific evidence to determine whether exploitation occurred locally.
Sequence is not always strictly linear. During active exploitation, containment, evidence preservation, remediation and investigation can proceed in parallel according to incident severity and operational constraints.
Worked example: what a KEV alert does and does not tell you
Assume CISA adds a remote code execution vulnerability affecting a network appliance to KEV.
| Evidence discovered | What you can conclude |
|---|---|
| CVE is in KEV | Exploitation has been observed in the wild. |
| Your organisation does not use the affected product | The vulnerability is not locally applicable based on the current inventory. |
| You run the product but already had a non-affected build | The specific vulnerable version was not present, assuming the inventory is accurate. |
| You ran an affected version on a public interface | You had a locally relevant exposure condition requiring urgent remediation and historical assessment. |
| IDS records an exploit payload but blocks it | An exploitation attempt may have reached the asset; successful compromise is not yet established. |
| EDR shows the vulnerable service spawning an unexpected shell matching documented exploitation behaviour | There is materially stronger evidence of successful exploitation and the incident should be escalated. |
This is why the phrase “actively exploited” cannot be translated directly into “my server was hacked.”
Where this fits with other TPS cybersecurity guides
Related TPS cybersecurity guides
Forminator vulnerability 2026
A specific example of why the installed plugin version and actual fixed release matter when a vulnerability advisory changes.
Malicious npm package check
A supply-chain incident workflow for separating package presence, malicious-code execution, secret exposure and remediation.
Verification notes: confirmed, interpreted and not established
Confirmed
- CISA adds vulnerabilities to KEV based on evidence of exploitation.
- BOD 26-04 uses KEV status and asset exposure in federal vulnerability prioritisation.
- BOD 26-04 includes pre-patch compromise checking in designated scenarios.
- FIRST distinguishes exploitation activity from guaranteed successful compromise.
Guidance-based
- NCSC recommends checking reachability of affected systems.
- NCSC recommends investigating compromise while remediating high-risk actively exploited flaws.
- FIRST says EPSS is not a complete organisation-specific risk score.
TPS interpretation
- KEV should be treated as global exploitation evidence, not local breach proof.
- An exposure window is critical when deciding whether historical investigation matters.
- Patching and incident-scoping should not be treated as the same outcome.
Not established by KEV alone
- that your product is affected;
- that your server was targeted;
- that an exploit succeeded;
- that credentials were stolen;
- that persistence exists.
Verification method
ThePulseSignal checked CISA material describing the Known Exploited Vulnerabilities Catalog and current KEV additions, CISA’s June 2026 BOD 26-04 announcement and its explicit pre-patch compromise-assessment requirement, CISA incident/vulnerability response guidance, FIRST documentation for EPSS and CVSS, and the UK NCSC’s May 2026 active-exploitation guidance.
Global exploitation evidence, local asset applicability, exploit attempts, successful exploitation and compromise are kept as separate evidence states throughout this guide.
Limitations and unresolved facts
This guide explains the evidence model. It cannot determine whether a specific system is compromised without vulnerability-specific and asset-specific evidence.
- A KEV entry can change remediation priority but does not identify every organisation targeted by attackers.
- Absence from KEV does not prove a vulnerability is not being exploited; exploitation can be incompletely observed.
- A low EPSS score does not override direct evidence that exploitation has already occurred.
- CVSS severity does not determine whether your particular deployment is exposed.
- A vulnerability scanner can produce false positives or identify software without proving the vulnerable execution path exists.
- An IDS or IPS exploitation alert may represent an attempted and blocked attack rather than successful exploitation.
- A clean current system does not automatically prove that compromise did not happen before patching.
- Indicators of compromise differ by vulnerability, product, attacker and post-exploitation behaviour.
- Logging gaps can prevent a definitive historical conclusion.
- BOD 26-04 is binding on US Federal Civilian Executive Branch agencies; other organisations can use its approach as guidance but are not made federally subject to the directive merely by this article.
CISA KEV: frequently asked questions
What does it mean when a CVE is in CISA KEV?
It means CISA has evidence that the vulnerability has been exploited in the wild and has added it to the Known Exploited Vulnerabilities Catalog. It does not mean every affected system has been compromised.
Does CISA KEV mean my server was hacked?
No. You must separately confirm that your server runs an affected configuration, that attackers could reach the vulnerable path and that local evidence supports attempted or successful exploitation.
If I patched a KEV vulnerability, am I safe?
The patch can close the vulnerability going forward. Whether further investigation is needed depends on whether the asset was exposed before remediation, the vulnerability’s impact and the applicable vendor, CISA or incident-response guidance.
Does an exploit alert prove the attack worked?
Not necessarily. Some security telemetry records exploitation attempts that were blocked. You need evidence of successful execution or subsequent attacker activity to make a stronger compromise conclusion.
What is the difference between KEV and EPSS?
KEV identifies vulnerabilities for which exploitation evidence already exists. EPSS estimates the probability that exploitation activity will be observed for a vulnerability during the next 30 days. EPSS is predictive and does not know whether your specific environment is affected.
What is the difference between CVSS and KEV?
CVSS describes vulnerability severity characteristics. KEV provides evidence that attackers have actually exploited a vulnerability in the wild. Neither by itself proves local compromise.
Should every KEV vulnerability trigger a forensic investigation?
No universal rule applies to every environment and every CVE. Investigation depth should reflect local applicability, exposure, exploit impact, observed evidence and vulnerability-specific authoritative guidance.
Can a vulnerability be exploited even if it is not in KEV?
Yes. Security organisations do not have complete visibility into every exploitation event. Absence from the catalog should not be interpreted as proof that exploitation has never occurred.
Bottom line
CISA KEV gives you high-value threat evidence: the vulnerability has been exploited in the wild.
But the investigation should continue through four separate questions:
Is my system affected? → Was it reachable? → Was exploitation attempted or successful locally? → Is there evidence of compromise?
If an affected asset was exposed while a high-impact vulnerability was actively exploited, patch quickly — but do not automatically treat the patch timestamp as the end of the incident question. Preserve the relevant evidence and follow vulnerability-specific guidance to determine whether compromise occurred before remediation.
Last verified: August 22, 2026. This guide reflects CISA’s current KEV framework, the June 2026 BOD 26-04 risk-based remediation approach, FIRST’s current EPSS and CVSS guidance, and NCSC’s May 2026 active-exploitation response guidance.