Notifications
Clear all
Topic starter
01/08/2026 10:50 pm
TL;DR: Across 122 vulnerabilities added to CISA KEV between October 2025 and March 2026, Nucleus found that eight had a public proof of concept before listing and that the median gap between PoC release and KEV entry was 5.5 days. That gap turns exploit code into an operational trigger long before formal confirmation arrives, and waiting for KEV is now a timing mistake, not a risk strategy.
NHIMG editorial — based on content published by Nucleus: Don't wait for KEV listing, because public PoCs can lead exploitation by days
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.
- When AWS credentials are exposed publicly, attackers attempt access within an average of 17 minutes.
Questions worth separating out
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.
Q: Why do public proof of concept releases change prioritisation so quickly?
A: Because they prove exploitability, not just theoretical weakness.
Q: How do security teams know whether exploitability is more urgent than severity?
A: Use exploitation evidence, not severity alone.
Practitioner guidance
- 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.
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.
👉 Read Nucleus' analysis of public PoCs and the KEV delay window →
Public PoC exposure: are your vulnerability workflows fast enough?
Explore further
01/08/2026 10:58 pm
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.
A question worth separating out:
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.
👉 Read our full editorial: Public PoCs create a 5.5-day exploit window before KEV listing
