What Is a Known Exploited Vulnerability (KEV)?

At KEVIntel, a known exploited vulnerability, commonly shortened to KEV, is a vulnerability for which there is credible evidence of real-world exploitation attempts.

A CVE identifies a publicly documented vulnerability. KEV intelligence shows that attackers are trying to exploit a vulnerability, sometimes before a CVE has been assigned or the flaw has been publicly disclosed.

At KEVIntel, we identify known exploited vulnerabilities through exploitation activity observed across our global honeypot and sensor network.

This helps security teams answer one of the most important questions in vulnerability management:

Which vulnerabilities are attackers actually trying to exploit?

The Vulnerability Prioritisation Problem

Tens of thousands of new vulnerabilities are disclosed every year.

Security teams receive findings from vulnerability scanners, cloud platforms, endpoint tools, code-scanning systems, penetration tests and vendor advisories.

The result is often a remediation backlog containing thousands, or even hundreds of thousands, of findings.

No security team can investigate and patch every vulnerability immediately.

Teams therefore need reliable ways to decide what deserves attention first.

One common approach is to prioritise vulnerabilities using the Common Vulnerability Scoring System, focusing on vulnerabilities with high or critical severity scores. This reduces the number of findings requiring immediate attention, but it does not solve the underlying problem.

Severity does not prove exploitation.

A critical vulnerability may never be targeted by attackers. A lower-severity vulnerability may already be used in automated attacks across the internet.

Known exploited vulnerability intelligence adds an important additional signal:

Is there evidence that attackers are actually trying to exploit this vulnerability?

What Makes a Vulnerability a KEV?

At KEVIntel, a vulnerability becomes a candidate KEV when our global honeypots or sensors observe activity consistent with an attempt to exploit a specific security flaw.

The observation must contain enough evidence to distinguish exploitation from routine scanning.

Useful evidence can include:

• A vulnerability-specific endpoint or parameter.
• A request structure associated with a known exploit.
• Input designed to trigger command execution, file access, SQL injection, SSRF, deserialization or authentication bypass.
• A product-specific exploit sequence.
• Behaviour that closely matches a recognised exploit fingerprint.
• Repeated observations across different sensors, source IPs or time periods.

A generic request for a homepage is not enough.

A version check is not enough.

A request for a commonly scanned administrative path may not be enough.

The activity must show credible exploit intent and support a sufficiently reliable mapping to a specific vulnerability, affected product or vulnerable behaviour.

Where a CVE has not yet been assigned, KEVIntel may initially track the activity using the affected product, endpoint, weakness type and observed exploit characteristics. Earlier observations can later be linked to a CVE once an identifier becomes available.

How KEVIntel Uses Its Global Honeypot and Sensor Network

KEVIntel operates a global honeypot and sensor network designed to observe exploitation attempts against internet-facing services.

These sensors collect technical evidence such as:

• HTTP methods.
• Request paths.
• Query parameters.
• Request bodies.
• Headers.
• User agents.
• Source IP addresses.
• Targeted products and services.
• First-seen and last-seen timestamps.

The activity is analysed and mapped to vulnerabilities, products, affected functionality and Common Weakness Enumeration categories.

KEVIntel uses globally distributed honeypots and sensors to collect exploitation telemetry, which we validate and curate for our customers.

The objective is not simply to collect suspicious internet traffic.

It is to determine whether that traffic provides credible evidence that attackers are targeting a known vulnerability, suspected zero-day or previously undocumented security flaw.

Scanning vs Exploitation

Not every suspicious request is an exploitation attempt.

Scanning usually tries to identify whether a product, service or endpoint exists. Exploitation attempts to trigger a security flaw and achieve an outcome such as command execution, file access, authentication bypass or data exposure.

A request for a login page may be reconnaissance.

A request containing a vulnerability-specific command-injection string is exploitation activity.

KEVIntel requires evidence of exploit intent and a sufficiently reliable mapping to the affected product, functionality or vulnerability. Generic product detection, version checks and routine internet background noise are not enough.

The growing use of AI-generated PoCs has introduced additional noise into internet scanning. Some requests may look like exploit attempts while targeting nonexistent endpoints, inventing parameters or failing to reach the vulnerable code path. These requests are not treated as KEV evidence merely because they claim to target a CVE. An exploit may fail against a sensor and still count, but it must be technically capable of exercising the underlying vulnerability.

How KEVIntel Validates Global Sensor Observations

Mapping internet traffic to a known vulnerability, suspected zero-day or previously undocumented flaw requires more than matching a URL or product name.

Different vulnerabilities can affect similar endpoints or produce similar attack patterns. Command injection, path traversal and SQL injection strings can also appear across many products.

KEVIntel therefore considers:

• Whether the request targets the affected product and vulnerable functionality.
• Whether its structure is consistent with exploitation of a particular flaw.
• Whether it attempts a meaningful security impact.
• Whether it matches a recognised exploit fingerprint.
• Whether similar activity has been observed across global sensors, sources or time periods.
• Whether another vulnerability or routine scanner could explain the activity.

The more specific and complete the evidence, the higher the confidence in the vulnerability mapping.

Ambiguous activity remains under review rather than being published as confirmed exploitation. Read more about the KEVIntel exploitation validation methodology.

Does a KEV Exploit Attempt Have to Succeed?

No.

An attacker does not need to compromise a system successfully for the activity to provide credible evidence of exploitation.

An exploit attempt may fail because:

• The target is patched.
• The target is a honeypot.
• The product version is not vulnerable.
• The request reaches an unrelated service.
• A required configuration is missing.
• The exploit contains an error.
• A mitigation interrupts the exploit chain.
• The attacker targets the wrong operating system.

Attackers often send the same exploit across large ranges of internet-facing systems without knowing which targets are vulnerable.

Some attempts may succeed. Others may reach patched systems, unrelated services or KEVIntel honeypots.

The vulnerability status of the target does not determine whether the request was a genuine exploitation attempt. KEVIntel analyses the request, targeted functionality and observed behaviour rather than requiring proof of compromise.

The key question is whether the activity can be confidently identified as an attempt to exploit a specific vulnerability or previously unknown security flaw.

Malformed requests, generic attack strings and routine scanner traffic must still meet KEVIntel’s validation threshold before they are treated as reliable exploitation evidence.

What Does Not Automatically Make Something a KEV?

The following signals are not sufficient on their own:

• A vulnerability has a critical severity score.
• Exploit code exists.
• A scanner check exists.
• A product endpoint was requested.
• A suspicious IP address accessed a system.
• A generic attack string appeared in a request.
• A vulnerability is technically easy to exploit.
• A bot requested a commonly targeted path.
• An AI-generated PoC or scanner request that is technically incapable of triggering the vulnerability.

These signals may justify further investigation, but they do not prove that attackers are exploiting the vulnerability in the wild.

KEV classification should be based on credible evidence, not assumption.

Why Confidence Matters

Not every observation across KEVIntel’s global honeypot and sensor network carries the same evidential weight.

A complete, vulnerability-specific remote-code-execution attempt provides much stronger evidence than a single request to a generic endpoint.

KEVIntel considers factors such as:

• Endpoint specificity.
• Product matching.
• Exploit-chain completeness.
• Similarity to recognised exploit patterns.
• Repeated observations.
• Observations across multiple global sensors.
• Whether the activity could be ordinary scanning.
• Whether another vulnerability could explain the same request.

This helps separate strong exploitation evidence from weak or ambiguous signals.

Sensor activity is only treated as reliable KEV evidence when the vulnerability mapping meets the required validation threshold.

Why Known Exploited Vulnerabilities Matter

Known exploited vulnerabilities allow security teams to prioritise based on attacker behaviour.

Instead of asking only:

How severe is this vulnerability?

Teams can also ask:

Are attackers trying to exploit it?

This provides a stronger basis for deciding what to patch, mitigate, monitor or investigate first.

Known exploited vulnerability intelligence can help teams:

• Prioritise remediation.
• Escalate vulnerable internet-facing assets.
• Reduce vulnerability-management noise.
• Investigate exploitation attempts.
• Create detection rules.
• Use virtual patch guidance to develop temporary WAF or IPS controls.
• Search historical logs for related activity.
• Identify targeted functionality and attack patterns.
• Track when exploitation was first and last observed.
• Monitor changes in exploitation volume.

KEV status should not be the only prioritisation factor.

Asset exposure, business criticality, affected versions and the potential impact of exploitation still matter.

A known exploited vulnerability affecting a product your organisation does not use is not relevant to your environment.

A known exploited vulnerability affecting an exposed identity system, firewall, VPN or business-critical application may require immediate action.

How Security Teams Can Use KEVIntel Observations

A practical KEV workflow can be reduced to four steps.

1. Match the KEV Against Your Assets

Determine whether the affected product and vulnerable version exist in your environment.

Where no CVE has yet been assigned, use the available product, endpoint and vulnerable-functionality details to identify potentially affected systems.

2. Assess Exposure and Importance

Identify whether the affected service is internet-facing, internally accessible or protected by another control.

Consider the importance of the system and the potential impact of exploitation.

3. Patch, Mitigate or Monitor

Apply the security update where possible.

Where immediate patching is not practical, temporary controls may include:

• Disabling the vulnerable functionality.
• Restricting access to the affected endpoint.
• Applying network controls.
• Creating detection rules.
• Deploying tested WAF or IPS rules (Virtual Patches).
• Monitoring for the observed exploit pattern.

For an unpatched or previously unknown flaw, containment and exposure reduction may be necessary until a vendor fix becomes available.

4. Hunt and Verify

Search existing logs for activity consistent with the exploitation patterns observed across KEVIntel’s global honeypot and sensor network.

After remediation, confirm that the vulnerable version is no longer exposed and that temporary mitigations are operating as intended.

Known Exploited Does Not Always Mean Currently Active

A vulnerability may have been exploited in the past without receiving significant activity today.

Known exploited status and current exploitation activity are related, but they are not the same thing.

This is why KEVIntel tracks global telemetry such as:

• First observed.
• Last observed.
• Number of exploitation attempts.
• Number of unique attacker IP addresses.
• Number of sensors that observed the activity.
• Targeted functionality.
• Recent exploitation trends.

This provides more context than a simple yes-or-no exploitation flag.

The fact that a vulnerability has been exploited matters.

The recency, volume and quality of the observations help determine how urgently teams should respond.

Common Misconceptions About Known Exploited Vulnerabilities

Every Critical Vulnerability Is a KEV

False.

Severity describes potential impact. Known exploited status requires evidence of exploitation.

Every Scan Is Exploitation

False.

Generic probing, fingerprinting and product detection should not automatically be classified as exploitation.

Exploitation Must Succeed

False.

A failed attempt against a patched system or honeypot can still show that attackers are targeting the vulnerability.

Every KEV Must Already Have a CVE

False.

Exploitation may be observed before a vulnerability is publicly disclosed or assigned a CVE identifier. The activity can be tracked using product and technical evidence, then linked to a CVE later.

Known Exploited Means Widespread Exploitation

False.

A vulnerability may become known exploited after a small number of credible observations.

From Vulnerability Noise to Exploitation Evidence

Security teams cannot treat every vulnerability as equally urgent.

KEVIntel’s global honeypot and sensor network identifies vulnerability-specific exploitation attempts, supports vulnerability mapping and helps separate meaningful attacker activity from routine internet scanning.

This includes exploitation of documented CVEs, flaws awaiting CVE assignment and potentially previously unknown vulnerabilities.

This gives defenders a clearer prioritisation signal:

Focus first on vulnerabilities attackers are actually trying to exploit.

Severity, asset exposure and business impact still matter.

Known exploited vulnerability intelligence adds the evidence needed to decide what deserves attention now.

Explore the KEVIntel Known Exploited Vulnerability Feed for evidence-backed exploitation intelligence, confidence scoring and sensor telemetry.