Public PoC Exploits are a Clear Signal for Defensive Action

Why a Public PoC Tilts the Field Toward Attackers 

Attackers and defenders are playing the same game by different rules. An attacker needs one piece of working code to act. A defender needs proof concrete enough to justify pulling a team off other work, often across thousands of open CVEs at once. A public PoC sits squarely inside that gap. It clears the attacker's bar instantly while defenders often wait for formal confirmation by CISA's Known Exploited Vulnerabilities (KEV) catalog. 

CISA KEV is the gold standard precisely because CISA requires validated evidence before listing a CVE. That discipline is what makes it trustworthy, and it is also what makes it lagging. By the time KEV confirms exploitation, attackers often have a head start. 

KEV Often Arrives 5.5 Days After Public PoC Exploitation Begins 

To quantify how much room attackers have, Nucleus reviewed all 122 vulnerabilities added to the CISA KEV catalog between October 2025 and March 2026. Twenty-two (18%) showed meaningful pre-KEV signals, and eight of those had a public PoC available before CISA’s listing. For the public PoC layer alone, the finding is unambiguous: it gave defenders measurable lead time in every case it appeared, with a median of 5.5 days between PoC publication and KEV listing. 

That 5.5-day window is response time defenders are leaving on the table when they wait for KEV confirmation.

Public PoC Is a Strong Early Signal 

A CVSS score and a vendor advisory give you reasons to plan a patch. A public PoC gives you a reason to escalate one. CVSS rates technical impact, the advisory describes the flaw, and neither shows whether the system can actually be breached. Working exploit code does, which is the evidence that justifies pulling engineering off planned work for an out-of-cycle fix. Most other signals can't anchor that decision on their own. EPSS spikes, forum chatter, vendor advisories, and KEV entries all need analyst judgment or community consensus before a team will act on them, and that consensus lag is the window attackers are already inside. 

A Simple Way to Think About Risk Levels

Stage 1: CVE Exists

Vulnerability identified and assigned an ID. Evaluate and triage.

Stage 2: PoC Available

Someone has demonstrated how to exploit it. Higher priority.

Stage 3: Weaponized exploit

Reliable and usable by less-skilled attackers. High urgency.

Stage 4: Active exploitation

Attackers are already using it in the wild. Emergency priority.

Three Cases That Escalated from Public PoC to Exploitation 

What does that look like in practice? Let’s look at three examples from the dataset where a public PoC dropped, defenders had the signal to act, and attackers acted on it first. The cases span the full range of PoC types observed, from a single-command GitHub script, to a published research write-up, to a fully packaged Metasploit module, with weaponization speeds ranging from hours to days. 

CVE-2026-24061, GNU InetUtils / telnetd: 2 Days, Fastest in the Set 

The tightest public-PoC-to-KEV window in the dataset belongs to a vulnerability that had been sitting undiscovered in telnetd for 11 years. The flaw, dormant since a 2015 commit, surfaced as CVE-2026-24061 on January 20, 2026. The PoC was a single string: USER=-f root, sent through Telnet's NEW_ENVIRON option, which made the login binary skip authentication and hand back a root shell. No credentials, no chained exploit, no privilege escalation step.

Within 48 hours of disclosure, researchers were tracking authentication-bypass attempts from more than 20 unique IPs, with three distinct attack waves starting January 22, progressing from probe-only payloads to downloader stagers fetching shell scripts. More than 212,000 Telnet-exposed devices were visible on the internet, with roughly 1 million devices listening on port 23. CISA added the CVE to KEV on January 26, two days after exploitation began. 

When a public PoC is weaponized it can be reliably exploited by less-skilled attackers, and the exploitation window collapses to hours. Defenders waiting for KEV gave up a valuable defense window. Attackers did not.  

CVE-2025-14847, MongoBleed (MongoDB): 4 Days, Scale of Exposure 

The public PoC for MongoBleed was published on GitHub on December 26, 2025, the day after Christmas, when security teams are typically understaffed. Critically, this is not remote code execution. The exploit tricks the server into returning chunks of uninitialized heap memory, which routinely contain credentials, API keys, session tokens, and PII, so the attacker outcome is credential theft and downstream compromise, not direct shell access. Active exploitation appeared within 24 hours, with attacker sessions burning 100,000+ connections per minute and skipping the client-metadata handshake that legitimate drivers always send. 

Roughly 87,000 internet-exposed MongoDB instances were vulnerable (about 20,000 in the US, 17,000 in China, 8,000 in Germany), and 42% of cloud environments ran at least one vulnerable instance. MongoDB Atlas was patched automatically; self-hosted deployments were not. CISA added the CVE to KEV on December 30, four days after the PoC dropped. 

The December 26 release date wasn't an accident. Security teams are thin between Christmas and New Year, and MongoBleed was the only early signal that fired before KEV listed the CVE four days later. Teams that weren't watching for public PoCs over the holiday had nothing else telling them to act. 

CVE-2025-37164, HPE OneView: 13 Days, Metasploit Module Drives a Botnet 

The most dramatic escalation in the dataset came from a CVSS 10.0 unauthenticated RCE in HPE OneView, which is enterprise infrastructure management software deployed across data centers. Three days after disclosure, on December 19, a Metasploit module was published hitting the unauthenticated /rest/id-pools/executeCommand REST endpoint, with a built-in chain to escalate from the OneView service account (trm3) to root via the older PwnKit vulnerability (CVE-2021-4034).

Three weeks later, on January 7, 2026, between 05:45 and 09:20 UTC, more than 40,000 automated attack attempts were observed in 3.5 hours and reported to CISA the same morning. CISA listed the CVE that day. There was an additional operational trap: HPE's hotfix is overwritten by routine appliance upgrades, so unless teams reapplied it after every upgrade, OneView returned to a vulnerable state on its own. 

A Metasploit module is the most dangerous form of a public PoC because it ships ready to run, with payload handling and post-exploitation built in. OneView is an assumed-breach scenario for that reason: a privileged management platform with broad network access and minimal monitoring is exactly the kind of target ransomware operators want. Once the module shipped, exploitation was a matter of time. OneView is also the cleanest example of stack signal: 166 social and traditional media mentions, weaponization indicators, patch availability, and executive scrutiny were all firing alongside the PoC, giving teams that watched the full picture a near-two-week head start before KEV listed. 

Public PoCs Reveal Predictable Attacker Behavior 

The three cases above weren't unique. Across all eight vulnerabilities in the dataset with a public PoC, two patterns held consistently. 

Pattern 1: PoC Type Appears to Shape the Speed of Weaponization 

Across the dataset, the type of public PoC appeared to strongly influence how quickly attackers moved. Public PoCs that were easy to use, automate, or operationalize, such as single-command GitHub exploits, Metasploit modules, or research publications with working exploit code, were consistently followed by exploitation within hours to just a couple days after release. While the sample size is still limited, the pattern was consistent: the easier and more operational the PoC, the faster exploitation appeared to begin, often making PoC type a stronger prioritization signal than CVSS severity alone. 

Pattern 2: Automation Collapses the Window 

The three cases above show the same shape at three different scales: 40,000 OneView attempts in 3.5 hours, 100,000 MongoBleed connections per minute, and a roughly 400% jump in telnetd scanning within 72 hours. Once a working PoC is public, exploitation goes automated and internet-scale within hours, not days. There is no gradual ramp for defenders to react to. KEV listings, which trail the activity, are confirming a state that's already underway. 

Public PoC Is Not the Only Early Signal 

Public PoCs are a strong early signal, but they do not cover every case. In our dataset, only about half of the pre-KEV exploitation cases had a public PoC, meaning teams that rely on them alone will still miss a meaningful share of active exploitation. 

The operational rule that falls out of the data: when a public PoC appears, treat it as a tier-1 trigger. When it is absent, lean on the surrounding stack: weaponization indicators, confirmed exploitation reporting, exposure context, vendor intelligence, and exploitability scoring. 

HPE OneView is the canonical “stack” case. The public PoC was one signal among many: a Metasploit module, 166 social and traditional media mentions; weaponization indicators, patch availability, and executive scrutiny were all firing in parallel. Teams that acted on the stack had nearly two weeks of a head start on enterprise infrastructure exposure. Teams that waited for KEV absorbed it.

Closing the PoC Exploitability Gap with Nucleus Insights 

A public PoC is a strong early indicator of risk, but it only becomes truly actionable when paired with the context defenders need to prioritize response. Nucleus Insights surfaces exploit pressure two ways:

• Flags, Exploited in the Wild, Exploitable, and PoC Available automate threat-informed decisions.
• A daily-refreshed Nucleus Threat Rating, five levels ranging from Low to Existential, captures the broader picture. 

Both are embedded in the Nucleus Platform and combined with asset and business context and ownership, so teams see what to fix first, who owns it, and why. 

The Clock Starts Ticking When a PoC is Released 

Treat a public PoC as the start of the clock. In this dataset, PoCs appeared 2 to 16 days before KEV listing, time defenders can use to patch, isolate, or monitor exposed systems before exploitation goes wide. KEV isn't the wrong signal; it's the late one. 

Read the full research for more insights. Also be sure to check out Part 1 and Part 2 of this blog series for in-depth analysis of our findings.