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.
Editorial analysis by NHI Mgmt Group, based on content published by Nucleus: “Public PoC Exploits are a Clear Signal for Defensive Action”.
Key questions
Q: What should teams do first after a public proof-of-concept appears?
A: Patch the exposed framework versions immediately, then verify that rebuilds and redeploys have removed the vulnerable path from production.
Q: Why is waiting for KEV listing too late in some cases?
A: KEV is designed to be validated, so it often confirms exploitation after attackers have already had usable code.
Q: What are the signs that a vulnerability has moved from disclosure to operational risk?
A: Public code, easy automation, packaged exploit tooling, and fast scanning activity are the clearest signs.
Practitioner guidance
- Prioritise public PoCs ahead of KEV listing Create a triage path that treats public exploit code as a higher-priority trigger than waiting for CISA KEV confirmation, especially for internet-facing assets.
- Score exploit maturity separately from CVSS Add PoC type, ease of use, and automation potential to vulnerability decisioning so single-command scripts, research write-ups, and packaged modules rank differently.
- Tie exposure decisions to asset criticality Combine exploitability with system ownership, service importance, and external exposure so remediation teams can justify pulling effort from lower-value work.
Bottom line: Public proof of concept releases create a practical exploit window before formal catalog listing, and that window can be long enough for attackers to move first.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
01/08/2026 10:58 pm
Public PoC availability is now an exploitability control problem, not a research curiosity. Once working code is public, the decision boundary changes for defenders because the attack path is no longer hypothetical. The article’s finding shows that waiting for KEV converts an early warning into a late validation step. Practitioners should treat exploit code as a governance signal that changes prioritisation, ownership, and response sequencing.
A question worth separating out:
Q: How should security teams combine KEV, PoCs, and exposure context when prioritising remediation?
A: Use KEV as one input, not the only one. Public PoC availability, exploit maturity, internet exposure, business criticality, and ownership should all shape the decision so that the highest-risk systems get attention before formal catalog confirmation arrives.
👉 Read our full editorial: Public PoCs create a 5.5-day exploit window before KEV listing