Unpatched Vulnerabilities Risks, Causes, and Fixes

Key Takeaways

• An unpatched vulnerability has a fix available that just hasn’t been applied yet.
• Mandiant’s M-Trends 2026 puts mean time-to-exploit at negative seven days, so on average attackers beat the patch.
• The 2026 Verizon DBIR found only 26% of detected KEV vulnerabilities fully remediated, with a 43-day median to get there.

Most security teams carry the same backlog. It holds the CVEs that got triaged, ticketed, scheduled, and then quietly deferred because the maintenance window collided with quarter-end close. Those are unpatched vulnerabilities, and exploiting them has become the leading known way attackers gain initial access.

The gap that matters sits between a patch existing and that patch actually running in production. The rest of this post looks at why it stays open and how to close it.

What counts as an unpatched vulnerability

An unpatched vulnerability is a known flaw with a fix available, running on a system where that fix hasn’t been applied. Three parts, all required: a known flaw, an available fix, and a system that still doesn’t have it.

That middle part, the available fix, is what separates it from its two neighbors.

A zero day gets exploited before defenders have had a fair chance to respond, usually before disclosure or before a patch exists. Until a fix ships, mitigations are all you’ve got. Our breakdown of how zero-day exploits work covers that case.

End-of-life software is the other neighbor. Fixes are possible, but the original vendor has stopped shipping them. CentOS 7, PostgreSQL 13, an EOL PHP branch – real CVEs, real exposure, no upstream support.

On paper, the unpatched vulnerability is the most avoidable of the three, since the fix already exists and is usually free. In practice, a free patch still costs testing time and a maintenance window, which is half the story of this post.

The disclosure-to-exploitation timeline is tighter than most patching cadences assume, and it doesn’t always run in order.

Stage	When it happens	What is happening
CVE disclosed, patch released	Same day, or weeks apart	Often paired for critical RCE
Public PoC or exploit code	Anywhere from before disclosure to weeks after	GitHub, exploit frameworks, research writeups
Mass internet scanning	Hours after a working PoC	Attackers fingerprint exposed instances at scale
Active exploitation, KEV listing	Can start before disclosure, and KEV listing comes after CISA confirms it	Now a confirmed, in-use attack vector

Severity and exploitation likelihood are different signals. A CVSS 9.8 on a service you don’t expose can be less dangerous than a CVSS 6.5 sitting on your edge. See our walkthrough of what changed in CVSS v4.0.

The real cost of unpatched vulnerabilities

Start with a number you should stop repeating: “unpatched vulnerabilities cause 60% of breaches.” That traces back to a 2019 Ponemon Institute survey for ServiceNow, and it shouldn’t be quoted as a current, industry-wide figure anymore.

Current data tells a sharper story. In the 2026 Verizon DBIR, 31% of breaches started with vulnerability exploitation, up from 20% the year before. That made it the leading known initial-access vector in Verizon’s dataset for the first time in the report’s history. Breaches also got pricier. IBM’s 2026 Cost of a Data Breach Report puts the global average breach at $4.99 million, a record.

Ransomware is the odd one out. In Sophos’s 2026 State of Ransomware survey, only 18% of ransomware victims traced the attack to an exploited vulnerability, down from 32% a year earlier, as malicious email and phishing took over as the leading root causes. Patching still matters here. It’s just no longer the only door in.

The damage lands as regulatory exposure, ransomware extortion, downtime, compliance findings, and a reputational tail that outlasts all of it. Our breakdown of the real-world costs of not patching a critical CVE goes deeper on each.

Three breaches show how this plays out, each a little differently.

Incident	CVE	Patch available	Exploitation	Fallout
Equifax	CVE-2017-5638 (Apache Struts 2)	March 7, 2017	Portal scanned and found vulnerable March 10, 2017, personal data accessed from May 13, detected July 29	147 million people, plus an FTC/CFPB/state settlement of at least $575 million
MOVEit Transfer	CVE-2023-34362	May 31, 2023	Cl0p mass exploitation as a zero day from May 27–28, 2023, and unpatched servers kept getting hit for weeks after	2,773 organizations, roughly 95.8 million individuals (Emsisoft)
Log4Shell	CVE-2021-44228	Log4j 2.15.0, December 10, 2021, with follow-up fixes days later	Scanning from December 1, 2021, mass exploitation within hours of disclosure	Nearly 40 million vulnerable Log4j downloads in 2025 alone, about 13% of that year’s total (Sonatype)

Equifax is the clean unpatched-vulnerability case. The fix shipped March 7, attackers were probing the portal three days later, and bulk data theft started 67 days after the patch became available. MOVEit and Log4Shell started as zero days, then turned into unpatched-vulnerability stories almost immediately, once fixes existed and plenty of installations kept running the vulnerable build anyway.

Why vulnerabilities go unpatched (the reasons teams rarely admit)

Each of these is a rational, local decision that adds up to an irrational result across the whole organization.

Reason	What it looks like	What removes it
Fear of downtime	Kernel CVE needs a reboot, and the host is stateful with no failover	Rebootless kernel patching
EOL software, no upstream patch	CentOS 7 host running an app that won’t build on anything newer	Vendor-backed extended support, or a funded migration date
Patches that never land	Automation reports 98% success. The other 2% are on the edge	Reconciliation between patch tooling and independent scans
Unknown assets	A 2021 staging VM, a contractor’s container, a forgotten subdomain	Continuous, always-on discovery
Testing overhead	Every patch regression-tested against a monolith nobody fully understands	Risk-tiered testing, with critical security fixes fast-tracked through staged rollouts
More CVEs than triage time	48,185 CVEs published in 2025. Three people can’t read that	Exploitability-based filtering

 Volume alone is a reason. Security researcher Jerry Gamblin’s analysis of 2025 CVE data counted 48,185 published records, roughly 132 a day, while FIRST’s own EPSS page suggests only a low single-digit percentage of published CVEs are exploited in any given 30-day window. Most of the queue won’t see an attacker this month. The hard part is knowing which sliver will.

Then there’s accumulation. Deferred patches compound into security debt the same way deferred refactors compound into technical debt, and the interest shows up as an incident. Scanner noise makes it worse, because teams that burn weeks chasing a false positive lose the credibility they need when a real one shows up. OS end-of-life status belongs in that same continuous discovery loop.

A common pattern in mid-size estates isn’t a team choosing not to patch. It’s an orchestration tool reporting success on a host that quietly drifted off the config management agent months earlier. Nobody lied. The reporting layer measured the wrong thing.

How attackers exploit unpatched vulnerabilities

Look at it from the attacker’s side. A zero day costs research time, or six figures and up on a broker market. An n-day, meaning a bug with a public fix, can cost little more than a Shodan query, provided there’s a working proof of concept and enough exposed targets to point it at. Attackers reach for zero days when they have to and n-days whenever they can, and the disclosure process restocks the n-day inventory every day.

Mandiant’s M-Trends 2026 report puts a hard number on how far that gap has collapsed. Mean time-to-exploit is now an estimated negative seven days, which means that, on average, exploitation starts before the patch ships. Exploits have held the top spot as the most common initial infection vector for six years running, now accounting for 32% of intrusions where Mandiant could identify the entry point.

CISA’s Known Exploited Vulnerabilities catalog is the public scoreboard for flaws that made the jump from theoretical to actively used, and it grows every week. The deadlines it drives for U.S. federal civilian agencies changed in 2026. BOD 22-01, which since 2021 had given agencies two weeks to fix KEV entries (six months for older CVEs), was replaced, along with the older BOD 19-02, by BOD 26-04, “Prioritizing Security Updates Based on Risk,” issued June 10, 2026.

Instead of one flat deadline, the new directive scores each vulnerability on four factors. Is the asset publicly exposed? Is the flaw in KEV? Can exploitation be automated? Does it give an attacker total control of the system, or only partial? The answers set the clock. The riskiest combinations get three days, and the highest-risk KEV cases with total control also require forensic triage to check whether the system was already compromised. Everything in between gets 14 or 60 days, and flaws that hit none of the four factors can wait for the asset’s next scheduled upgrade.

Many heavily exploited flaws are remote code execution bugs in internet-facing services and edge devices, and sometimes the vulnerable system isn’t even yours to patch. MOVEit is the clearest recent example. A flaw in one widely used file transfer product turned into thousands of downstream victims.

For federal civilian agencies, three days is now the ceiling for the worst tier, and a weekly change advisory board can’t hit it. If your fastest possible response to an actively exploited, internet-facing RCE takes longer than three days, that’s a process gap worth closing before the next one lands.

How to stop unpatched vulnerabilities from piling up

This is a process problem with five moving parts, and skipping straight to prioritization before you’ve built an inventory just means prioritizing a subset you can’t fully name.

Find every unpatched vulnerability first

Coverage beats sophistication here. A perfect prioritization model covering 70% of your estate does less for you than crude triage covering all of it.

Build your inventory from more than one angle, since every source misses something different. Config management and agent inventory miss anything that’s drifted off the agent. Cloud provider APIs miss on-prem systems and shadow accounts. Authenticated network scanning misses hosts that were powered off during the scan window. DNS and external attack surface discovery is what catches the subdomain nobody remembers owning.

Then reconcile. The useful part is where those lists disagree. A host that shows up in your cloud inventory but not in your scanner results is exactly the kind of gap that gets you breached. Once the asset list holds up, map each host’s installed packages and versions against the advisories that apply to them, so you know which of those hosts are actually vulnerable.

Check that reported patches actually landed, too. A newer kernel package sitting on disk doesn’t mean the running kernel is protected. Unless the host rebooted into it or got a live patch for that CVE, it’s a vulnerability wearing a “remediated” label.

Prioritize by real exploitability

Raw CVE counts measure workload. Real risk needs three more inputs.

Start with KEV. A listing means confirmed in-the-wild exploitation, so if it touches your assets, patch it now, regardless of CVSS. Then check the EPSS score, a daily-updated probability from 0 to 1 that a published CVE gets exploited in the wild over the next 30 days. It’s free, machine-readable, and built for exactly this decision. Last, weigh exposure and business importance separately. Is the asset internet-facing or reachable from systems an attacker could already be on? Does it hold sensitive or regulated data?

FIRST’s own comparisons make the efficiency case well. A blanket CVSS 7-and-up rule pulls a huge slice of the queue into remediation, while an EPSS threshold catches a large share of what actually gets exploited for a small fraction of the work. There’s no universal cutoff to copy, though. The right threshold depends on your own queue.

If your team’s under-resourced, start with KEV plus exposure and layer in EPSS later. If you already patch KEV reliably, EPSS is where the next tier of risk reduction comes from.

Patch fast, and remove the reasons you can’t

Speed comes from cutting friction out of the process. Automate deployment so patching runs as a pipeline instead of a one-off project, since a patch that needs a human to schedule it tends to get scheduled late.

Then deal with the reboot dependency directly. Reboots are one of the most common reasons kernel patches sit unapplied. They force a maintenance window, a change ticket, and someone awake at 2 a.m. confirming the host came back up. Rebootless patching, sometimes called live patching, applies the fix to the running kernel in memory, so for supported vulnerabilities the hole closes without an outage.

KernelCare does this across the major enterprise Linux distributions, so a mixed estate doesn’t need a separate tool per OS, and 24/7 workloads stop trading uptime for CVE exposure.

Cover EOL software that has no vendor patch

Everything above assumes the vendor still ships a fix. For EOL components, the original vendor doesn’t, and the standard advice to just upgrade skips over why the system’s still running in the first place.

Usually it comes down to hardware that won’t run a newer kernel, an application whose vendor only certified one OS version, regulatory validation that would need redoing from scratch, or engineering bandwidth that’s already committed three quarters out. A stern email about EOL dates fixes none of them.

That leaves three workable options.

Option	Best when	Watch for
Migrate now	The app is portable and you have capacity this quarter	Slips are normal, and exposure continues during the slip
Compensating controls only	Fully isolated, no untrusted input path	Isolation degrades quietly. One firewall change reopens it
Vendor-backed extended support	You need CVEs closed while migrating on your own schedule	Confirm exactly which OS packages, runtimes, and libraries are covered

That third path is what TuxCare’s Endless Lifecycle Support handles. It delivers security patches for the runtimes, libraries, frameworks, and applications that have aged out of upstream support, along with the EOL Linux distributions underneath them, through standard package management. Covered systems keep getting security fixes, with a paper trail to match, while migration happens on a timeline the business can actually fund.

Verify remediation and prove it

Patching without verification is a belief system. Two things make patch status hard to trust.

The first is silent failure. The package got installed, but the service never restarted, or the host rolled back, or the update landed on the base image and not the running container. The second is a false positive. A scanner reads a version string, misses a backported fix, and flags a closed CVE as still open.

Good verification produces a few concrete things. You get confirmation, straight from the running system, that the fixed code is actually loaded, plus a reconciliation between your patch tooling’s report and an independent scan. Each host and CVE gets a dated, exportable record that’s ready for an auditor. And your tickets treat “remediated” as confirmed, with “attempted” tracked as its own separate status.

Backport-aware verification is the weak point on Linux, since generic scanners routinely misread packages in which the distribution backported a fix while keeping the upstream version number. Whatever scanner you run, check its findings against the distribution’s own security advisories before you burn a sprint on a CVE that’s already closed.

How TuxCare closes the gap

The gap between “patch available” and “patch running” is where a lot of breaches happen. Equifax had the fix for 67 days before the data theft started. With Log4Shell, attackers were already active before the first patch existed. Teams that close that gap tend to be the ones who removed the structural reasons for delay, namely EOL dead ends, vulnerable packages that keep sneaking back into builds, and reboots.

TuxCare’s approach maps to those three directly. Endless Lifecycle Support covers the runtimes, frameworks, applications, and operating systems their upstream vendors have already walked away from. SecureChain swaps public registries for a TuxCare-managed one, with screened, continuously patched packages for JavaScript, Python, Java, Go, and PHP, which helps keep known-vulnerable versions out of new builds. KernelCare handles rebootless kernel patching across mixed Linux environments. Pick whichever piece matches your risk profile.

Start with an inventory you trust. Then decide what to fix first.

FAQs