Exploited Before CISA KEV: What 8 Confirmed Cases Reveal

31 days. That’s how long attackers were exploiting a vulnerability in Gogs before CISA added it to KEV, with no patch available and remote code execution on the table. 

CISA KEV Is a Confirmation Signal, Not a Warning System 

Most vulnerability programs are built to act when risk looks obvious, such as when a vulnerability lands in CISA KEV, a public exploit emerges, or EPSS rises. This approach is rational because it provides a clear, defensible trigger for action. But it often comes with delay: by the time signals are strong enough to drive consensus, the window to get ahead of risk may already be closing. 

CISA’s KEV catalog is the clearest example. It was designed to give government agencies and the broader community a trusted, validated signal of real-world exploitation, and that bar is intentionally high. The same design that makes KEV authoritative is also what makes it slow: a vulnerability must be exploited, observed, and validated before it ever reaches the catalog. By the time KEV lists a CVE, attackers have often already been operating against it for days or weeks. 

Time-to-Exploitation Has Collapsed 

The window between disclosure and exploitation has collapsed. For years, the lag between vulnerability disclosure and active exploitation gave defenders a comfortable buffer. Mandiant’s M-Trends 2024 report found that average time-to-exploit dropped by approximately 92% from 2018-19 to 2023. The buffer that made waiting on KEV safe has disappeared.

That makes pre-KEV exploitation the most dangerous phase of the lifecycle: it’s the window when a vulnerability is not yet clearly visible or prioritized. Even a few days of lead time matter, because attackers do not wait for consensus. They move quickly, increasingly using AI to accelerate and scale exploitation before defenders can act. 

We Analyzed Every KEV Addition for 6 Months – Here’s What We Found 

Between October 2025 and March 2026, Nucleus reviewed every new vulnerability added to CISA KEV, 122 in total, to answer a single question: can vulnerabilities be exploited before they are added to KEV? For each one, we looked backward for attacker-relevant signals before the listing date, including confirmed exploitation, public proof-of-concept activity, weaponization, ransomware involvement, vendor and commercial threat intelligence, and rising research or media attention. 

The data showed that 8 of those 122 vulnerabilities had confirmed exploitation in the wild before being listed on KEV, with a median lead time of 5.5 days and a range stretching from 1 to 31 days.

Download the Exploitability Intelligence Gap White Paper

Exploited Before CISA KEV: The Cases That Prove It 

Across the eight confirmed pre-KEV exploitation cases, one stands above the rest. Gogs sat exposed for 31 days before CISA listed it. That was long enough for an attacker to plan, persist, and pivot through any environment running it. The shorter cases tell a different but equally instructive story. Notepad++ shows how fast a public PoC turns into a real attack. FileZen shows what happens when ransomware is already in play. Chromium shows that even a 48-hour gap is enough for a competent operator to do real damage. 

Four cases concentrate the pattern most clearly. Each represents a different threat profile, a different signal mix, and a different reason that waiting for KEV would have left defenders behind.

CVE	Product	Days Before KEV	Key Pre-KEV Signal
CVE-2025-8110	Gogs	31	Zero-day, RCE, no patch
CVE-2025-15556	Notepad++	7	Public PoC, weaponization
CVE-2026-25108	FileZen	7	Ransomware, RCE
CVE-2026-2441	Chromium	2	RCE, active exploitation

Gogs (CVE-2025-8110): 31 days 

Gogs had the widest gap in the dataset, and the most damning case in it. Gogs is a self-hosted Git service, the kind of internal developer tool that sits behind the firewall and rarely gets the same scrutiny as internet-facing infrastructure. Attackers were exploiting it a full 31 days before KEV listed it, and during that month the warning signs were already clear: easy exploitation, remote code execution, zero-day status, and no patch available. There was no fix to deploy even if a team had caught it early. The only lever defenders had was detection and containment, and most teams never knew to look. By the time KEV listed it, anyone waiting on confirmation was more than four weeks behind on a vulnerability that was already being actively exploited with no fix in sight. 

Notepad++ (CVE-2025-15556): 7 days 

This case shows how quickly a public PoC turns into a real attack. Notepad++ is one of the most widely installed text editors in enterprise Windows environments. It is the kind of software that lives on developer machines, analyst workstations, and IT desktops without anyone tracking it as an attack surface. A public proof-of-concept dropped, attackers picked it up almost immediately, and within days it had been weaponized and linked to malware activity. The 7-day gap is almost entirely explained by how fast that pipeline ran. It is a clear example of why public PoCs are early warning signs. Teams that treat them otherwise had no chance to act before exploitation was confirmed. 

FileZen (CVE-2026-25108): 7 days 

FileZen tells the same 7-day story, but with a sharper edge. The pre-KEV signal mix included ransomware activity alongside weaponization and remote command execution, which means the exploitation wasn’t the result of opportunistic scanning. It was a targeted attack with a financial motive already in play. Seven days before KEV, a ransomware operator was already using this vulnerability. 

Chromium (CVE-2026-2441): 2 days 

Chromium had the shortest gap in the set, at just two days. That sounds manageable until you map it against what an attacker can do in 48 hours: establish initial access, set up persistence, and begin moving laterally before a defender has a confirmed signal to act on. With Chromium running on nearly every endpoint in a modern enterprise, even a narrow window represents a meaningful blast radius. 

The Signals Were There: The Problem Was Connecting Them 

The signals defenders need to act early are often visible in the wild. The challenge is that they live in different places, arrive in different formats, and rarely line up neatly enough to drive a confident prioritization decision. These signals surface across public research, threat intelligence, vendor advisories, and community discussion, often days or weeks before KEV listing. They include: 

• Public proof-of-concept activity
• Spikes in EPSS scores
• Exploit weaponization and malware activity
• Vendor and commercial threat intelligence
• Media volume and community attention 

Each signal arrives in a different place, in a different format, and on a different cadence. A public PoC sits in a research feed. EPSS movement lives in a scoring tool. Ransomware involvement is buried in a threat intelligence report. Vendor advisories arrive on their own schedules. Each piece is suggestive on its own; none is conclusive. Teams end up piecing together fragments across disconnected sources, which slows action and stretches the window of exposure. 

Closing the gap between evidence and action (aka, the exploitability intelligence gap) is fundamentally an integration problem. Teams may have access to the upstream evidence they need, including public PoCs, weaponization indicators, vendor intelligence, and threat feeds. What they lack is a way to consolidate those signals into a single prioritization workflow before formal confirmation arrives, and a way to defend the resulting decisions internally.  

How Nucleus Helps Teams Close the Gap Between Evidence and Action 

Nucleus understands that exploit intelligence is critical to effective prioritization, which is why Nucleus Insights delivers a first-party vulnerability intelligence feed that brings exploit signals, threat context, and business impact directly into exposure management workflows.

Security teams can leverage Nucleus Insights, which enriches each vulnerability with threat and business context, and integrates that intelligence directly into vulnerability and exposure management workflows so they can continuously prioritize and drive action at scale.  

With Nucleus Insights, teams can: 

• Consolidate fragmented signals into a unified view of exploitability
• Act on credible early evidence before KEV, EPSS, or public consensus
• Reduce exposure using a continuously updated signal called Nucleus Threat Rating (NTR)
• Shrink exposure windows by moving decisions upstream 

The system to operationalize signals exist. The remaining gap is how fast teams can mobilize action. 

Stop Reacting on Attacker Timelines 

Programs that wait for KEV, EPSS, or public consensus before prioritizing are operating on attacker timelines, not their own. The eight cases in the white paper show that meaningful evidence often surfaces days or weeks before formal confirmation: in our examples, 31 days for Gogs, 7 for Notepad++ and FileZen, 2 for Chromium. The cost of waiting is measured in real exposure. As time-to-exploitation continues to shrink, the teams that reduce exposure fastest will be the ones that learn to act on layered evidence before the rest of the market reaches consensus. 

Read the full Exploitability Intelligence Gap research report for the complete picture across all 122 vulnerabilities, including EPSS behavior before and after KEV and the role of public proof-of-concept activity, or request a demo to see how Nucleus turns these signals into action.

Learn More About the Exploitability Intelligence Gap

Join us on Wednesday, May 6, 2026 for our webinar, The Exploitability Intelligence Gap: What Security Teams Can Know Before CISA KEV, to learn more about the research and take a deep dive into the white paper’s findings.