Public PoCs create a 5.5-day exploit window before KEV listing

At a glance

What this is: Nucleus found that public proof of concept releases created a median 5.5-day head start before CISA KEV listing in its six-month dataset.

Why it matters: For security and identity practitioners, that means prioritisation models based on formal confirmation alone can leave exposed systems, credentials, and privileges unprotected while attackers automate exploitation.

By the numbers:

• Across all 122 vulnerabilities added to the CISA KEV catalog between October 2025 and March 2026, 22 showed meaningful pre-KEV signals.
• 17 minutes.

👉 Read Nucleus' analysis of public PoCs and the KEV delay window

Context

Public proof of concept code changes vulnerability management because it converts a theoretical flaw into evidence that exploitation is already practical. For vulnerability and identity teams, that matters whenever exposed services, privileged credentials, or remote management interfaces can be reached before a formal listing arrives.

The key governance gap is timing. CISA KEV is intentionally validated and therefore lagging, while attacker automation begins as soon as working code appears. In practice, that means teams need to act on exploitability signals, not only on later confirmation, especially where non-human identities, service accounts, or management-plane access are involved.

Key questions

Q: What breaks when organisations wait for KEV before patching new CVEs?

A: Waiting for KEV creates a blind spot because exploitation often starts before formal catalogue inclusion. Teams that rely on KEV alone miss early scanning, active weaponisation, and high-risk internet-facing flaws that are already being used in the wild. Exposure-based triage plus live threat telemetry is a safer decision model.

Q: Why do public proof of concept releases change prioritisation so quickly?

A: Because they prove exploitability, not just theoretical weakness. A public PoC tells defenders that working attack code exists and that the effort required for exploitation has dropped sharply. That is especially important for internet-facing assets, privileged interfaces, and systems with weak segmentation or high-value credentials.

Q: How do security teams know whether exploitability is more urgent than severity?

A: Use exploitation evidence, not severity alone. A high CVSS score says the flaw could be serious, but KEV status and EPSS together tell you whether attackers are likely to use it soon. If a vulnerability is already on the exploited list, remediation should move ahead of non-exploited issues with similar or even higher theoretical scores.

Q: Should organisations rework vulnerability response around public PoCs?

A: Yes. Public PoCs should trigger a faster workflow that combines exposure assessment, ownership, patch planning, and identity review for any affected admin or service credentials. KEV remains useful, but it should sit behind exploitability signals in the decision chain when the PoC is already public.

Technical breakdown

Why public proof of concept code matters more than severity

CVSS describes impact, but it does not prove exploitability. A public proof of concept shows that a vulnerability can be translated into working attack code, which sharply reduces the attacker’s effort and raises the operational urgency for defenders. That is why exploit code often becomes a better prioritisation input than severity alone when teams face large backlogs of open CVEs. The presence of a PoC does not guarantee exploitation, but it does remove ambiguity about feasibility. In practice, security teams should treat PoC availability as a control-breaking event, especially where internet exposure or privileged management paths exist.

Practical implication: elevate public PoC sightings into out-of-cycle triage, not the regular patch queue.

Why KEV often lags the real attack window

CISA KEV is valuable because it uses validated evidence, but that validation requirement also makes it slower than attacker activity. The article shows that defenders can lose several days between PoC release and KEV listing, even when exploitation pressure is already building. That lag is not a flaw in KEV, it is a property of evidence-based listing. For practitioners, the lesson is to treat KEV as confirmation of a problem that may already be underway, not as the first moment a vulnerability becomes operationally relevant. Exposure context, exploitability, and observed activity need to be considered together.

Practical implication: combine KEV with exploitability and exposure signals in your prioritisation workflow.

How PoCs become automated exploitation at scale

Once a public PoC is available, the barrier to entry drops for both skilled operators and opportunistic attackers. The article’s cases show a familiar progression: proof of concept, then weaponisation, then internet-scale automation. That progression matters because it compresses the time available for patching, isolation, and compensating controls. In environments where exposed services, weakly monitored management planes, or service accounts are in play, a short automation window can be enough for compromise. For identity teams, the analogue is clear: once a working exploit can reach a credential or token boundary, standing access becomes a liability rather than a convenience.

Practical implication: prepare containment actions before public PoCs appear, not after automated scans start.

Threat narrative

Attacker objective: The attacker’s objective is to convert newly published exploit code into fast, scalable access before defenders complete formal prioritisation.

1. Entry begins when a public proof of concept is released and attackers can validate the flaw against exposed services or internet-facing management planes.
2. Escalation follows as exploit code is weaponized into automated scanning, mass probing, or packaged modules that reduce attacker effort and expand reach.
3. Impact occurs when defenders are still waiting for formal confirmation and the exploit is already being used to gain code execution, steal credentials, or drive further compromise.

NHI Mgmt Group analysis

Public proof of concept release is now a control-breaking event. The central governance mistake is treating exploit code as a research artifact rather than an operational change in attacker capability. Once working code is public, the decision threshold for exploitation drops and the defender’s window narrows. The practical conclusion is that vulnerability governance must promote PoC sightings into the same priority lane as confirmed exploitation when exposure is material.

KEV is a confirmation mechanism, not a pacing mechanism. CISA’s validated approach makes KEV trustworthy, but trustworthiness is not the same as timeliness. Teams that wait for catalog inclusion are implicitly assuming the attack surface will remain static long enough for evidence to catch up. That assumption fails when scanning and automation begin immediately after PoC publication. Practitioners should treat KEV as one input in a broader exploitability model, not the trigger itself.

Standing access and exposed management paths become the real multiplier once a PoC exists. The article’s examples show that exploitable flaws become worse when they intersect with internet exposure, privileged interfaces, or credentials that can be reached without strong segmentation. In identity terms, that is a reminder that service accounts, admin consoles, and operational tokens are only as safe as the shortest exploit path to them. The governance conclusion is that blast radius, not patch intent, determines whether a PoC becomes an incident.

Exploitability now competes with vulnerability count as the key prioritisation concept. We call this PoC exploitability gap: the period in which a flaw is already actionable for attackers but still sitting below defender attention because formal confirmation has not arrived. That gap is where modern vulnerability management fails first. Security leaders should use the concept to reset how they define urgent work, because the most dangerous CVEs are increasingly the ones with working code, not just high scores.

Identity control boundaries still matter even in a vulnerability-led story. When public PoCs target authentication bypasses, memory disclosure, or management-plane access, the downstream exposure often includes tokens, service accounts, or administrative credentials. That makes IAM, PAM, and secrets governance part of vulnerability response, not a separate discipline. The practical takeaway is to connect exploit intelligence to identity containment actions before the exploit path reaches privileged resources.

What this signals

PoC-driven exploitation turns vulnerability management into an identity problem as soon as credentials, tokens, or admin paths are exposed. That means vulnerability teams and IAM teams need a shared escalation path for assets that can be reached through service accounts or privileged interfaces. The useful operational concept here is the PoC exploitability gap, and it closes only when exploit intelligence and identity containment move together.

For practitioners, this should change how response queues are built. Public PoC sightings need to feed compensating controls, not just patch tickets, and the teams responsible for IAM, PAM, and secrets should be in the loop when a flaw can expose authentication boundaries. See the 52 NHI Breaches Analysis for patterns where credential exposure becomes the real incident path.

The broader signal is that formal confirmation will keep lagging attacker action, so the programme that wins is the one that can move on early proof, exposure context, and ownership clarity. Where vulnerable systems sit behind shared secrets or unmanaged service credentials, the response needs to be faster than the normal change cadence. That is exactly where identity governance stops being a back-office control and becomes an incident-prevention mechanism.

For practitioners

• Trigger PoC-based escalation rules Move any vulnerability with a public PoC into an expedited triage lane that includes exposure review, exploitability scoring, and owner assignment before the next patch cycle.
• Tie vulnerability intake to identity containment When a PoC affects authentication, memory disclosure, or management interfaces, check for exposed service accounts, tokens, and admin credentials at the same time as patch planning.
• Shorten response playbooks for internet-facing assets Create a separate runbook for internet-exposed services, because PoC publication can collapse the response window from days to hours once automation begins.
• Treat KEV as a downstream signal Use KEV as confirmation, but do not wait for it before isolating vulnerable assets, disabling risky interfaces, or applying compensating controls when PoC evidence is already public.

Key takeaways

• Public proof of concept code now creates a measurable exploit window before KEV listing, which makes waiting for formal confirmation too slow for high-exposure assets.
• The article’s dataset shows that the most dangerous vulnerabilities are the ones where working code, internet exposure, and automation line up before defenders move.
• Security teams should connect exploit intelligence to identity containment, because exposed credentials, service accounts, and admin paths are often the real blast-radius multiplier.

Key terms

• Proof of Concept: A controlled live test that checks whether a candidate provider works in the buyer's real environment with real data or realistic samples. It is used to validate performance claims, uncover integration issues, and expose gaps that written responses cannot reliably reveal.
• Exploited vulnerability catalog: An exploited vulnerability catalog is a curated list of flaws known to be used in real attacks. It matters because active exploitation changes priority. In practice, it helps security teams separate theoretical risk from issues that require urgent remediation and tighter operational oversight.
• PoC Exploitability Gap: The time between public exploit code becoming available and defenders treating the vulnerability as urgent enough to act. This gap matters because attacker effort drops immediately, while organisational response often still waits for a slower confirmation signal such as KEV or broader consensus.
• Exposure Context: Exposure context is the combination of data sensitivity, location, accessibility, and business impact that determines how risky a dataset is. In practice, it lets security teams move beyond raw access counts and judge whether an allowed permission creates acceptable or excessive risk.

What's in the full report

Nucleus' full research covers the operational detail this post intentionally leaves for the source:

• The six-month KEV dataset and how Nucleus separated pre-KEV signals from confirmed exploitation.
• Case-by-case timelines for CVE-2026-24061, CVE-2025-14847, and CVE-2025-37164, including weaponisation speed.
• The practical signal stack used to prioritise public PoCs alongside exposure, media, and patch availability.
• How Nucleus Insights translates exploit pressure into Flags, Exploited in the Wild, and Exploitable states.

👉 The full Nucleus research covers the case timelines, signal stack, and exploitability model in detail.

Deepen your knowledge

NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, secrets management, and workload identity. It helps practitioners connect identity controls to the broader security programme that protects exposed systems and privileged access.