Exploitability Without Exploitation: When Attention Is the Signal
Part 4 of 4 | The Exploitability Intelligence Gap Series
Nucleus Insights flagged 14 vulnerabilities with real-world exploitation activity that looked risky before CISA added them to KEV. The key takeaway: all 14 were later listed in KEV. Acting on those signals would have been the right call every time, just earlier.
First Take: Exploitability is the Key Early Signal to Act On
Over six months, from October 2025 to March 2026, Nucleus reviewed every vulnerability added to CISA’s KEV catalog. Of the 22 CVEs that showed meaningful pre-KEV signals, only 8 had confirmed exploitation before listing. The other 14, the majority, were exploitable and attention-heavy with no confirmed exploitation at the time, and every one of them still landed on KEV later. Exploitability, not exploitation, was the early signal teams should have acted on. The three previous blogs in the Exploitability Intelligence Gap series asked one question: how early can we see exploitation coming? This last blog asks a different one: what do we do when the signals are loud, but exploitation is not yet confirmed?
Key Definitions
Exploitability vs. exploitation. Exploitability is the capacity to be attacked: a working PoC, remote access, an available patch that reveals the bug, weaponization context. Exploitation is confirmed, observed use in the wild. A vulnerability can be exploitable long before, or without ever, being confirmed as exploited.
Can a vulnerability be urgent without confirmed exploitation? Yes. When multiple non-exploitation signals stack, the operational risk justifies acting before exploitation is verified.
Early Exploitability Signals Usually Stack Up Before Exploitation
The exploitability signal stack is the set of independent indicators that a vulnerability can be attacked and is drawing attention. No single one of them confirms an attack is underway, but the more that occur at the same time, the more urgent the vulnerability becomes.
The Exploitability Signal Stack
How attackable it is:
- Public proof-of-concept (PoC): working exploit code is publicly available.
- Weaponized exploit: a packaged, ready-to-run exploit such as a Metasploit module that even low-skill attackers can use.
- Remote, unauthenticated access: the flaw can be triggered over the network with no login required.
- High CVSS severity: a critical technical impact, for example remote code execution.
- Patch available: If a fix is available, attackers can diff the before and after to understand the impact behind exploitation. Without a fix, defenders are left in the dark beyond detection of actual exploitation.
How visible and widespread it is:
- Media and community attention: news coverage, social volume, and research or forum chatter.
- EPSS movement: a rising exploit-probability score (useful, but usually a late signal; see Part 2).
- Vendor or CISA advisory: an official acknowledgment that raises the vulnerability’s profile.
- Exposure and install base: many internet-facing or widely deployed instances.
- Asset criticality: privileged or management-plane systems, such as HPE OneView and EPM, where one flaw has a wide blast radius.
Ransomware or malware links: association with known criminal tooling or campaigns.
Teams Should Act When Multiple Signals Fire Together
Each of the signals above is easy to dismiss in isolation. “It’s just a PoC.” “It’s just press.” “It’s just an advisory.” Taken one at a time, none of them forces a decision. But the argument here isn’t about any single indicator. It’s about what happens when several of them accumulate on the same vulnerability. Read the graphic below as the thesis in one image: urgency comes from how many signals stack up on a row along with the number of media mentions. The rows with the most signals firing at once, namely OneView, EPM, and MongoDB, are exactly the ones that demanded action first.
That reframes the threshold. The question stops being “has this been exploited?” and becomes “how much operational weight has accumulated around it?” A working exploit plus remote access plus an available patch plus a wave of media attention is a different risk than any one of those alone, even when the “confirmed exploited” box is still empty.
Not everything exploitable becomes exploited, and that’s fine. The point is that a tall stack of signals carries a cost, and that cost should raise the priority of a fix, especially as multiple signals and media mentions start stacking up at the same time.
Three Vulnerabilities Had Stacked Signals Days Before KEV
Three short stories of the same pattern at three different speeds. Read together, they make the case that the stack was visible and KEV was the lagging confirmation, not the alarm.
HPE OneView (CVE-2025-37164): The Celebrity That Acted Exploited Long Before It Was Confirmed
HPE OneView is different from everything else in the set, because no vulnerability stacked more signals or stacked them louder. It never needed a confirmed-exploitation flag to prove how dangerous it was.
The bug itself was about as bad as they come: a CVSS 10.0 unauthenticated remote code execution flaw in the software that manages entire data centers, exactly the kind of privileged platform attackers hope to find. A public proof-of-concept appeared within days, followed by a full Metasploit module that chained straight to root.
Additionally, it drew 166 media mentions, more than four times the next vulnerability in the set, and it was the only one whose EPSS score jumped before KEV, simply because so many signals were firing at once. By the time CISA confirmed it 13 days later, any team that had been waiting for that confirmation had already lost nearly two weeks of exposure on a critical system. The stack had said everything the KEV listing eventually would, just far earlier.
Ivanti Endpoint Manager / EPM (CVE-2026-1603): The Full Stack Sat in Plain Sight for Almost Three Weeks
EPM tells the quieter version of the same story, and it shows just how long the signals can sit in the open. For Ivanti’s Endpoint Manager, a public proof-of-concept, a vendor patch, and remote exploitability were all available a full 18 days before KEV, the second-longest head start in the entire set, with media coverage building alongside them.
Like OneView, EPM is a management platform that reaches across thousands of endpoints, so a single flaw carries an unusually wide blast radius. Nothing about it was hidden. The evidence was simply waiting to be read, and 18 days is an enormous amount of lead time to leave unused while waiting for someone else to confirm what the signals already showed.
MongoDB “MongoBleed” (CVE-2025-14847): The Stack Still Fired on a Holiday Weekend Built to Catch Teams Off Guard
The MongoDB vulnerability, nicknamed “MongoBleed,” shows that the signals fire even when the timing is designed to slip past defenders. The public proof-of-concept dropped on GitHub on December 26, when most security teams are at their thinnest.
The flaw isn’t remote code execution. It leaks chunks of server memory that routinely hold passwords, tokens, and personal data, so the attacker’s reward is stolen credentials and everything those credentials unlock. Everything a defender needed to act was visible: a patch was available, the bug was remotely exploitable, it drew 28 media mentions, and roughly 87,000 instances were exposed on the internet.
KEV followed just four days later. The window was short and the holiday made it shorter, but the signals were out in the open for any team watching for them rather than waiting on a list.
Key Takeaway
OneView, EPM, and MongoDB look nothing alike: a celebrity RCE, an 18-day slow burn, a holiday memory leak. The constant is the stack. In every case, the signals were readable days to weeks before KEV, and in every case, KEV was the confirmation that arrived late, not the alarm that warned in time.
Attention is its Own Signal, for Attackers and for Your Brand
Attention isn’t only a symptom of risk; it’s a force that acts on its own. The moment a vulnerability becomes visible, that visibility starts creating pressure from two directions at once, and both directions land on the same security team at the same time.
Pressure from Attackers
Elevated visibility attracts adversaries. Media volume and community discussion act as a flare that pulls opportunistic and targeted attackers toward a CVE. The same attention that moves EPSS moves attacker interest, which is why a high-profile vulnerability rarely stays quiet for long.
Pressure from Your Organization
Visibility also raises executive scrutiny, customer concern, and board-level attention. A vulnerability in the press is one your CEO, your customers, and your auditors are already asking about, whether or not it has been exploited in your environment. The question “are we exposed to this?” lands on a security team long before any KEV listing does.
That is why exploitability without exploitation is a real operating condition, not a theoretical edge case. Long before any KEV listing, the attention itself is already generating work, risk, and questions you have to answer.
Plenty of Dangerous Vulnerabilities Never Reach the KEV List at All
All 14 of the vulnerabilities did reach KEV. However, many signal-heavy vulnerabilities never do. KEV is a deliberately high-bar catalog, and plenty of real exploitability never gets a listing, even as KEV itself feeds federal mandates and compliance directives like CISA BOD 26-04, which raises the stakes of treating it as the finish line.
If your only escalation trigger is KEV, or EPSS, or confirmed exploitation, every one of those signal-heavy CVEs is invisible to you by design. You cannot tell in advance which one fades and which becomes a problem, so the operating question can’t be “will this be exploited?” The right move is to read the stack on its own terms.
How to Act on Early Warning Exploitability Signals
A simple operating model:
- Look at the whole picture, not one checkbox. Add up what you already know: is there working exploit code, can it be reached remotely, is there a patch, how much attention is it getting? Don’t wait for a single “confirmed exploited” stamp before you act.
- Decide your trigger ahead of time. Agree in advance how many stacked signals, or how much attention, will make you act early, so a high-profile vulnerability meets a ready plan instead of a fire drill. CISA’s Stakeholder-Specific Vulnerability Categorization (SSVC) offers a credible framework for this, separating exploitation status from automatability, technical impact, and mission prevalence to guide a Track / Attend / Act decision, and automate vulnerability triage at scale.
- Factor in where it lives. The same vulnerability is more urgent on an exposed, internet-facing, or high-value system than on an isolated one. Use that to decide what to fix first.
- Match the response to the evidence. A tall stack of signals is a reason to move a fix up the queue and watch closely. It is not a reason to treat every news story as a live attack. Let the size of the stack set how hard you push.
To aggregate signals from across the security landscape and let teams act early, Nucleus Insights pulls the scattered indicators, including PoC, weaponization, patch and vendor context, exploitability characteristics, and media and community attention, into one view. The Nucleus Threat Rating (NTR) turns them into a single, daily-refreshed score, so “the stack lit up” becomes a number a team can act on and defend internally, without waiting for KEV or EPSS to catch up.
Set Your Threshold Before the Next High-Profile CVE Is Exploited
We’ve seen that KEV confirms late, that EPSS often confirms risk after it emerges, and that a public PoC is only one layer of the picture. The common denominator is that waiting for confirmation means starting too late, and the attention and exploitability signals you would act on are already in your hands.
This blog confirms that multiple exploitability signals tend to stack up together, and that stacking is itself the signal for teams to act. Organizations that want to address risk before exploitation should set that threshold early, while the next high-profile CVE is still hypothetical.
Request a demo of Nucleus today to see how your team can turn exploitability signals into earlier, more coordinated action.
Read the First Three Articles in the Series
If you missed them, be sure to go back and read the first three articles in this blog series.
See Nucleus in Action
Discover how unified, risk-based automation can transform your vulnerability management.
