Known vulnerabilities are still being exploited in 2026 because most organisations have two problems: finding flaws and fixing them. Only one is getting solved. The industry is good at discovery. Patch advisories, CVE databases, and CISA's Known Exploited Vulnerabilities (KEV) catalog generate more data than teams can act on. But the gap between knowing a flaw exists and actually closing it, verified across every affected system, stays wide. Attackers live in that gap.
The Numbers Behind the Problem
The Edgescan Vulnerability Statistics Report 2026 puts the average remediation time for critical application vulnerabilities at 54.81 days. Qualys's 2026 Enterprise Patch and Remediation Benchmark found an average of five months and ten days for enterprise applications, once change approvals and rollback planning are included.
On the other side: the Mandiant M-Trends Report confirms the median time to exploit a known vulnerability has dropped to under five days from disclosure.
Defenders are working on month timelines. Attackers are working on hour timelines. That gap is where the damage happens. Brandefense's H1 2026 research added something harder to ignore: CISA's KEV catalog documents exploitation of vulnerabilities up to 18 years old. Real organisations. Known flaws. Never fixed. This is not a sophisticated attacker problem. It is a closing-the-loop problem.
Six Reasons the Remediation Gap Stays Open
The patch gap is not one failure. It is several compounding problems that together leave organisations exposed for months, sometimes years.
Reason 1: CVSS Scores Are Not Risk Scores
Most patch programmes sort vulnerability backlogs by CVSS severity rating and work downward. That seems logical until you understand what CVSS actually measures: theoretical severity at disclosure. It does not adjust when active exploitation is confirmed. It ignores whether a working exploit exists or whether the flaw is live in this week's ransomware campaign.
July 2026 made this concrete. Microsoft's Active Directory Federation Services vulnerability (CVE-2026-56155) received a CVSS score of 5.3. Microsoft called it "Moderate." The National Vulnerability Database independently scored it 9.8. CISA added it to the KEV catalog the same day patches shipped and gave federal agencies three days to remediate.
Hackerstorm's research found that CVSS performs near random chance in predicting real-world exploitation likelihood. Teams prioritising by CVSS alone are effectively guessing which vulnerabilities matter most.
Reason 2: Asset Visibility Is Incomplete
You cannot patch what you cannot see. Indusface's 2026 report found that over 40 percent of organisations lack full visibility into their API attack surface. ManageEngine identified incomplete asset inventory as the primary driver of patching delays. Developers spin up cloud resources outside procurement. Contractors leave internet-facing environments behind after their engagements end. Every asset your inventory misses is an entry point your remediation never reaches.
Reason 3: Patch Volume Has Outpaced Human Capacity
In 2025, a record 48,185 CVEs were published. Microsoft's July 2026 Patch Tuesday alone covered 622 CVEs. No security team can triage every one. Tanium's research confirms the result: organisations delay patching primarily to avoid business disruption. Patches sit in an approved-but-not-deployed state for weeks while the application window gets deferred. Indusface found that 32 percent of identified vulnerabilities remained unpatched after 180 days.
Reason 4: Patching Is Not the Same as Remediation
Applying a patch and verifying the vulnerability is closed are two different things. Research cited by Automox found that over 80 percent of security leaders have discovered patches they believed deployed had failed to reach all affected endpoints. Silent failures. The Verizon Data Breach Investigations Report 2025 found that around 60 percent of breaches involved known vulnerabilities where a patch was already available. For context on what proper post-patch verification looks like, see the guide on what happens after a pentest.
Reason 5: Remediation Ownership Is Unclear
Security teams find the vulnerabilities. Engineering teams own the systems. Change management controls the deployment window. No single team has authority over the timeline. The result: tickets move between teams, get re-prioritised each sprint, and age out without ever being confirmed closed.
Reason 6: Supply Chain Complexity Creates Hidden Exposure
Even organisations with strong patching discipline can be exposed through dependencies. Log4Shell is the textbook case. Years after the original patch, it kept appearing in breach investigations because teams fixed their core systems while missing embedded copies inside third-party tools and forgotten services. They patched what their inventory told them to patch. The inventory was incomplete.
Your Last Pentest Is Already Out of Date
Every week you ship without continuous testing is a week a vulnerability goes unseen. See what Capture The Bug finds in your first engagement.
What Closing the Gap Actually Requires
Organisations materially reducing their exploitable exposure share a few clear habits. They treat asset inventory as a live, continuous activity. They prioritise using the CISA KEV catalog as the primary urgency signal rather than CVSS. And they verify that patches actually worked by testing whether the vulnerability remains exploitable in production, not just checking that a deployment record exists.
This is one of the structural advantages of continuous penetration testing for SOC 2 and ISO 27001 compliance. When a patch is deployed, it can be validated against the real attack vector to confirm the exposure is genuinely closed. That verification step is what most patch programmes skip.
For ANZ and US organisations, regulatory pressure makes this urgent. The Australian Essential Eight Maturity Level 3 requires critical patches within 48 hours. CISA's BOD 26-04 set binding three-day deadlines for KEV-listed vulnerabilities for federal agencies. And the ManageMyHealth breach, which exposed 126,000 patient records in New Zealand, showed exploitation of legacy gaps in the ANZ region is not theoretical.
Annual pentests cannot keep pace. six months of continuous testing across 100 ANZ SaaS products by Capture The Bug found attack patterns that rarely surface in standard point-in-time engagements. continuous PTaaS is how you move from knowing what your posture looked like months ago to knowing what it looks like right now.
The Bottom Line
Known vulnerabilities are still being exploited in 2026 because knowing is not fixing, and fixing is not verifying, and verifying once is not continuous assurance. The industry does not have a knowledge problem. It has a closing-the-loop problem.
If you want to find where your remediation programme leaves gaps, the most useful next step is not another scan. It is a rigorous test of whether the vulnerabilities you believe are closed are still exploitable in your production environment right now.
Book a free security consultation with Capture The Bug to find out exactly where your remediation gaps are at the Request Demo page.
Plan Your Annual Pentesting Strategy the Right Way
Learn how modern SaaS companies structure pentesting across the year to reduce risk, stay compliant, and avoid last-minute panic before audits.
FAQ
Why do known vulnerabilities keep getting exploited if patches are available?
Patching has multiple failure points: incomplete asset inventory, CVSS-based prioritisation that misses actively exploited flaws, silent deployment failures, and remediation ownership spread across teams with no single accountable party. The gap between a patch being available and being confirmed effective across every production system is where most exploitation happens.
What is the patch gap and why does it matter?
The patch gap is the time between a vulnerability being disclosed and an organisation fully remediating it. The Edgescan 2026 report puts the average at 54.81 days for critical application vulnerabilities. Since the median time to exploit has dropped to under five days (Mandiant M-Trends), most organisations spend most of their remediation lifecycle inside the active exploitation window.
Why do CVSS scores fail to accurately prioritise patching?
CVSS measures theoretical severity at disclosure and does not adjust when active exploitation is confirmed. Hackerstorm's research found CVSS performs near random chance in predicting real-world exploitation likelihood. CISA's KEV catalog is a more reliable signal because it reflects confirmed in-the-wild exploitation.
How does continuous penetration testing help close the remediation gap?
Continuous penetration testing treats verification as an ongoing activity. After patches are deployed, security testers attempt to exploit the same vulnerability in the production environment to confirm it is genuinely closed, rather than assuming deployment records are accurate.
What do Australian and New Zealand organisations need to know about vulnerability remediation timelines?
Australia's Essential Eight Maturity Level 3 requires critical patches within 48 hours of disclosure. APRA CPS 234 sets broader vulnerability management obligations. New Zealand's Privacy Act 2020 requires reasonable security safeguards. Many ANZ organisations now use the CISA KEV catalog as an internal remediation benchmark.
