BCN-T1-PRC-001Tier 1 · CriticalProcessing Protection

Known-Exploited Vulnerabilities

Unpatched CVEs with confirmed exploitation in the wild, on systems an attacker can reach.

Remediation SLA: 24 hours
Tier: 1 · Critical
Domain: Processing
Escalation: CISO and executive sponsor notified at 48 hours

What this finding is

A system carries a vulnerability that is confirmed to be exploited in the wild — the authoritative reference being the CISA Known Exploited Vulnerabilities catalog — and the vulnerable component is reachable by an attacker. Beacon deliberately keys this finding to observed exploitation rather than to CVSS score, because the two correlate weakly.

Why it is Tier 1

Confirmed exploitation removes all the uncertainty that normally governs patch prioritisation: working exploit code exists, someone is using it, and targets are being selected by scanning rather than by choice. The KEV catalog is a small fraction of published CVEs but accounts for a hugely disproportionate share of successful intrusions, which makes it the single highest-yield patching signal available and the reason Beacon separates it from routine vulnerability management.

Most common misclassification

High-CVSS vulnerabilities with no evidence of exploitation are often escalated into this finding. A CVSS 9.8 with no known exploitation and no reachability is Tier 2; a CVSS 6.5 in the KEV catalog on an internet-facing host is Tier 1. Exploitation evidence outranks score.

How to detect it

1Cross-reference your vulnerability inventory against the CISA KEV catalog on every scan cycle, and treat matches as a distinct queue rather than as high-severity items in the main backlog.
2Incorporate EPSS scores to prioritise among CVEs not yet listed in KEV but with high modelled exploitation probability.
3Confirm reachability before assigning the tier — an unreachable KEV entry is Tier 2, and treating every KEV match as Tier 1 will exhaust the queue's credibility.
4Extend coverage to appliances, hypervisors, and network equipment, which are heavily represented in KEV and thinly covered by host-based agents.

How to remediate it

Steps are ordered. The first step is the one that reduces exposure fastest, which is not always the one that closes the finding.

1Patch. Where a maintenance window is the obstacle, escalate rather than defer — the KEV designation is the justification for the emergency change.
2Where patching is genuinely blocked, apply the vendor mitigation and record it with an explicit review date rather than closing the finding.
3Remove reachability as a compensating control — withdrawing internet exposure converts an emergency into scheduled work.
4Hunt for prior exploitation using the indicators published with the CVE, since KEV entries frequently predate detection in your estate.
5Feed each occurrence back into patch-cadence planning; a recurring KEV backlog is a process finding, not a series of unrelated incidents.

How to verify the fix

The affected component reports a fixed version, an authenticated re-scan no longer detects the CVE, and — where a mitigation was applied instead — the compensating control is tested and carries a dated review.