The Vulnerabilities That Never Get a CVE

July 2026

Most vulnerability programmes run on a simple assumption: if a flaw matters, it gets a CVE, and if you watch the CVE feed and patch what appears, you are covered. The research says otherwise. Around 25% of open-source projects fix security bugs silently, without ever filing a CVE or disclosing the fix to any official repository (Sawadogo et al., 2020). The CVE feed most programmes are built on is not a complete record even of the software flaws it claims to track, so a team can patch everything it is told about and still be exposed to fixes it was never told about.

Get articles like this delivered to your inbox. Subscribe to CyberDesserts for practical security insights, no fluff.

Call this a silent patch: a security-relevant fix that ships with no CVE and no advisory. The academic literature calls it a silent vulnerability fix. The practice is old and it is common, and for a defender it is a genuine blind spot, and not the one most people worry about. This is not a piece about whether silent patching is ethical. It is about what it does to the tracking surface you rely on, whether your software runs on-premises or in a cloud tenant, and whether it comes from a commercial vendor or an open-source maintainer.

What silent patching is

A silent patch is a fix that closes a security-relevant flaw but was never framed as security. Sometimes there is no CVE. Sometimes there is no advisory. Sometimes the changelog line reads "fixed a parsing issue" with no hint that the issue had a security dimension.

It helps to separate this from two things it resembles. A silent patch is not an unpatched CVE sitting in your backlog, because the fix has usually already shipped. Nor is it an incomplete patch that fails to close the hole, which is its own problem. The distinguishing feature is narrower: the work was done and the record was not created, so the fix protects everyone who took the update while remaining invisible to anyone tracking what changed.

And the record is thin even when a CVE does exist. Analysis of the National Vulnerability Database found the link to the commit that actually fixes a vulnerability missing in roughly 70% of CVE records (arXiv study on NVD patch links, 2024). So the gap is not only the fixes that never got a number. It is also the numbered fixes whose tracking data was never completed. The CVE record is incomplete inside its own domain, before you even reach the flaws it never captured at all, and the official surfaces built on top of it inherit the same blind spots.

It happens by accident and by design

The first kind is accidental. In May 2026, Microsoft shipped a fix for a SharePoint deserialization remote code execution flaw, CVE-2026-45659, as part of the May cumulative update. The CVE itself was inadvertently omitted from the May 2026 Security Updates and the advisory was only corrected on 27 May (MSRC advisory revision 1.1, confirmed by Microsoft SharePoint engineer Stefan Goßner). Any team that reviewed May's published SharePoint CVEs saw nothing to track. Microsoft had rated the flaw "Exploitation Less Likely". On 1 July, CISA added it to the Known Exploited Vulnerabilities catalogue after confirmed exploitation in the wild, with a remediation deadline two days later (The Hacker News; CISA). For six weeks, the fix existed but the published CVE list gave defenders nothing to prioritise against, and the gap between those two facts is where the exploitation moved.

The same accidental silence reaches the most widely deployed software there is. The upstream fix for a Linux kernel privilege-escalation flaw in the epoll subsystem, later tracked as CVE-2026-46242 and nicknamed "Bad Epoll", landed in the mainline tree on 24 April 2026. It arrived unmarked as security-critical, and roughly 70 days passed before a researcher's public writeup on 3 July drew attention to it, by which point many distributions still had no backport shipped (Chung, 2026). There was no in-the-wild exploitation and no KEV listing at disclosure, only a working proof-of-concept. But for those ten weeks the fix was in mainline while defenders had nothing telling them it mattered, on a subsystem that essentially every Linux server and Android device relies on.

The second kind is by design, and harder to fix because nothing malfunctioned. In March 2026, researcher Justin O'Leary reported a privilege-escalation flaw in Azure Backup for AKS to Microsoft, which assessed it as expected behaviour requiring pre-existing administrative access and declined to issue a CVE. O'Leary disputes that, and CERT/CC independently validated the finding. The technical merits are contested and both positions are on the record. What matters for a defender sits underneath the dispute: Microsoft is itself a CVE Numbering Authority with final authority over CVE issuance for its own products, so a flaw that one party fixes and another declines to number can end with no trackable public record, whichever way the disagreement lands (BleepingComputer, 2026).

This is not a Microsoft problem. O'Leary reported a flaw of the same class to Google, which also declined, citing a requirement for pre-existing privilege (The Register). Two of the largest software vendors on earth, the same outcome: a finding, a disagreement, and no CVE for defenders to key on.

What drives it

Some of it is deliberate. Maintainers are advised to keep security detail out of public commit messages so that attackers cannot weaponise a fix before users have applied it (Cheng et al., 2025). The commit ships, the hole closes, and the security relevance is left unstated for a window. That is coordinated disclosure working as designed, not negligence.

Much of it is more mundane. Writing back in 2016, Caleb Fenton listed the reasons fixes go undisclosed: the security implications get overlooked, the maintainer never realises a bug had a security dimension, there are not the resources to file and track a CVE, or there is a reluctance to admit the flaw existed.

Economics runs through several of them. Documenting the security relevance of every fix competes with feature velocity under shipping pressure, and when a release is going out there is an order of prioritisation. "Write this up as a security advisory and request a CVE" often sits below the line, not because anyone decided it did not matter, but because it was never the most urgent thing in front of the person shipping. The fix goes out because it is ready. The advisory that would have told defenders it mattered does not get written.

There is an uncomfortable edge to this. The same coordinated-disclosure discipline meant to protect users is part of what disconnects the fix from any record a defender can follow. The quiet assumption most of us carry, that a fix at least gets communicated to the people running the software, is the thing that fails.

Why the silent patch is a defender problem specifically

This is where it matters for the defender. The silent patch is not hidden from everyone equally.

Google Project Zero puts it plainly: a public source-code patch is usually equivalent to disclosure, even when it is not marked as a security change. Attackers analyse patches through source review and binary comparison and reconstruct the flaw in full. What Project Zero also notes is that the utility of that information is not symmetric. An attacker studying one patch in depth is running a very different economics from a defender who has to keep an entire estate current and cannot afford that depth of analysis on every quiet commit.

So the flaw stays discoverable to anyone willing to read the commit history with intent, and invisible to the defender who relies on advisories to know what changed. The attacker was never the one kept in the dark. That gap sits entirely inside vulnerability management's own domain. This is not the broader argument that your attack surface is bigger than your CVE list, true as that is. It is narrower and more awkward: the CVE list is not even a complete account of the software flaws it claims to cover.

What this means for how you patch

The practical answer is not "patch more". You cannot patch harder against a fix you were never told about.

What changes instead is the trigger. A programme that updates only when a CVE tells it to is blind to silent patches by construction: no CVE, no trigger, no update. A programme that stays current on a cadence absorbs them as a side effect. You get the undocumented security fix because you took the update, not because anyone told you it mattered. That makes currency something you schedule rather than something you wait for the feed to prompt.

Defenders already have the other half of this reflex, and it is already mandated. When a known-exploited flaw cannot be closed by patching, CISA's Known Exploited Vulnerabilities catalogue does not tell agencies to wait. Under Binding Operational Directive 26-04, the required action becomes applying mitigations per vendor instructions, or discontinuing use of the product where no mitigation exists (CISA, 2026). The instinct is to reduce blast radius and restrict exposure until a fix is available, and it is exercised routinely.

The silent patch is the same problem with the trigger removed. You cannot mitigate against a fix you were never told shipped, so the only stance that holds is to assume the software is flawed whether or not a record says so. The zero-day is a different problem, an unknown flaw with no fix at all rather than a known one whose fix went unannounced, but from the defender's seat the response is the same. Neither can be patched on the day it matters, and containment does not need to know which kind it is facing. Treat every application as though it carries a failure you have not been shown, segment and constrain so that a misbehaving component cannot reach much beyond itself, and you close the same doors whether the flaw behind them was silently patched or never disclosed to anyone.

That stance has a name and a discipline. Treating vulnerability management as exposure management rather than CVE enumeration is what continuous threat exposure management sets out to do, and it is the strategic home for everything in this piece. Currency closes the gap on fixes that shipped without announcement; exposure management covers the flaw nobody has found yet. Neither depends on the CVE feed being complete, which is the point, because it never was.

The guardrails this leaves you with

If the record cannot be trusted to be complete, a programme cannot rest on it. Three guardrails follow from that, and each one assumes the thing you are defending against is the fix you were never shown.

Stay current as a matter of course, not because the feed tells you to. This is the one guardrail that catches a silent patch rather than just containing the damage. A programme that only updates when an advisory fires never updates for a fix nobody announced, and the packages it leaves alone, the ones with no open CVEs, are exactly what a silent patch moves through.

Watch for security-relevant change behind routine version bumps. A quiet fix looks identical to an ordinary bug fix. If it takes a CVE to make you look, the change goes in unread.

Build containment for the flaw you will never see. Segmentation, least privilege, and exposure reduction hold whether or not you knew the hole was there. When the trigger never fires, containment is what is left.

None of this depends on knowing what you are missing, which is the only honest place to start. The CVE feed was always a floor rather than the whole surface, and the record beneath it was never complete. A programme built on that record is not wrong about any single patch. It is wrong about the ones it was never shown.

Silent patching is not going away, and the tracking surface is not going to get more complete on its own. Subscribers get practical security analysis like this when the landscape shifts.

References and Sources

1. Sawadogo, A. D. et al. (2020). Learning to Catch Security Patches. Finding: around 25% of open-source projects fix vulnerabilities silently, without disclosing to any official repository. Referenced in later silent-fix retrieval literature (PatchSeeker, 2025).
2. arXiv (2411.11646). (2024). Can Highlighting Help GitHub Maintainers Track Security Fixes? Finding: the patch commit link is missing in roughly 70% of NVD CVE records on average, with availability far lower before 2020.
3. Microsoft Security Response Center, via Stefan Goßner (Microsoft SharePoint escalation engineer). (2026). MSRC advisory revision 1.1 for CVE-2026-45659. Confirms the SharePoint deserialization RCE was fixed in the May 2026 cumulative update but the CVE was inadvertently omitted from the May 2026 Security Updates. Source.
4. The Hacker News / CISA. (2026). CVE-2026-45659 added to the Known Exploited Vulnerabilities catalogue. Confirms KEV listing on 1 July 2026 after confirmed exploitation, following an "Exploitation Less Likely" rating. Source.
5. Chung, J. (2026). Bad Epoll (CVE-2026-46242), CompSec Lab, Seoul National University. Primary research repository and root-cause writeup. The fix commit (a6dc643c6931) landed in the Linux mainline tree on 24 April 2026; the public writeup followed on 3 July, roughly 70 days later, with many distributions still lacking a backport. No confirmed in-the-wild exploitation or KEV listing at disclosure. Primary source; corroborating coverage: The Hacker News.
6. BleepingComputer. (2026). Microsoft rejects Azure Backup for AKS vulnerability report; no CVE issued. Carries both Justin O'Leary's account and Microsoft's position that the behaviour is not a vulnerability; documents CERT/CC's VU#284781 and closure under CNA-hierarchy rules. Source.
7. The Register. (2026). Researcher reports same confused-deputy class to Google; bug bounty declined. Supports the industry-wide framing beyond Microsoft. Source.
8. Cheng, X. et al. (2025). Silent vulnerability fixes under coordinated disclosure. Finding: maintainers deliberately keep security keywords out of commit messages to avoid tipping attackers before users patch. Cited in PatchSeeker (2025).
9. Fenton, C. (2016). Why Most Vulnerabilities Are Never Disclosed. Taxonomy of reasons fixes go undisclosed: overlooked implications, lack of awareness, lack of resources, reluctance to admit the flaw. Source.
10. Google Project Zero. (2025). Vulnerability Disclosure FAQ. Finding: a public source-code patch is usually equivalent to disclosure even when unmarked, and the utility of that information is asymmetric between attackers and defenders. Source.
11. CISA. (2026). Binding Operational Directive 26-04. The required action for KEV entries becomes applying vendor mitigations, or discontinuing use where no mitigation exists.