TLDR
Patch management has been called best practice for decades, yet organizations keep getting breached through vulnerabilities that had patches available. The real failure is not slow patching across the board. It is patching without a coherent prioritization model. CVSS scores, the tool most teams rely on to decide what gets patched first, are a poor predictor of what attackers actually target. Build your patch program around exploitability evidence and asset exposure, and you will be working from the same data your adversary uses.
The Numbers That Should Embarrass Everyone
In 2024, more than 40,000 CVEs were published. Of those, VulnCheck confirmed roughly 768 (about 2% of the total) were actually exploited in the wild. Security teams, meanwhile, are triaging every finding above a 7.0 CVSS score as urgent, which in large environments translates to a patching queue that is permanently backlogged.
That backlog has consequences. The Equifax breach is the clearest example on record. CVE-2017-5638, a remote code execution flaw in Apache Struts, was patched and publicly disclosed on March 7, 2017. On March 9, Equifax administrators were told to apply it. On March 10, attackers breached the system through that exact vulnerability. The exfiltration went undetected for 76 days. By September 2017, data on 147 million Americans had been stolen and the company faced a $1.38 billion settlement.
The patch existed. The team knew about it. The process failed anyway, and that failure is not unique to Equifax. It is what patch management programs, as they are typically designed, reliably produce.
How Fast Attackers Actually Move
Before discussing what to prioritize, it is worth establishing the operating environment practitioners are actually working in.
VulnCheck’s analysis of 2024 exploitation data found that 23.6% of known exploited vulnerabilities were weaponized on or before the day their CVE was publicly disclosed. By the first half of 2025, that figure had risen to 32.1%. Akamai researchers observed active exploitation attempts against CVE-2024-4577, a PHP remote code execution vulnerability, within one day of its disclosure. The average time from disclosure to exploitation beginning is roughly four days.
On the defender side, a 2025 analysis drawing on Mandiant data found that 50% of critical CISA Known Exploited Vulnerabilities remained unpatched 55 days after a fix became available. Attackers need less than a week. Defenders are taking nearly two months on critical findings that are actively being exploited in the wild.
That gap does not close by patching faster in general. It closes by patching the right things faster, which is a different problem entirely.
The CVSS Trap
Most patch management programs are organized around CVSS scores. Findings rated 9 or 10 go to the front of the line, 7s and 8s follow, and anything below a 7 waits. This is intuitive, widely adopted, and demonstrably misaligned with how exploitation actually works. FIRST, which maintains the CVSS standard, explicitly states that base scores should not be used alone for prioritization. Most organizations use them that way regardless.
Research published by Sophos X-Ops, analyzing over 28,000 vulnerabilities, found that bugs with a CVSS score of 7 are the most frequently weaponized. Critically-rated vulnerabilities, those scoring 9 and 10, are actually less likely to have exploits developed than vulnerabilities rated 8 or 9. FIRST’s own research found that only about 2.3% of vulnerabilities scoring 7 or higher see actual exploitation attempts in a given month.
When you organize your patching queue around CVSS severity, you are not organizing it around attacker behavior. You are organizing it around a theoretical worst-case scoring model that attackers do not use. The result is teams burning time and change-management capital on high-CVSS findings that nobody is actively exploiting while medium-severity vulnerabilities on internet-facing systems with public proof-of-concept code sit in the backlog.
The Equifax vulnerability carried a CVSS score of 10.0. The team was aware of it. The patch was applied to some systems and missed on others. A perfect-10 CVSS score did not make it easier to prioritize. It may have contributed to the kind of organizational inertia that assumes someone else is handling it.
The Stability Argument Is Real, But Misapplied
This is where the dilemma framing earns its keep. Change management exists for real reasons. Patches break production systems. In operational technology environments, healthcare systems, and legacy infrastructure, a failed patch can cause operational failures that are worse than the vulnerability it was meant to fix. These are not excuses. They are genuine constraints that any practitioner managing those environments knows firsthand.
The problem is that organizations apply the same caution uniformly, across internet-facing web applications and air-gapped internal systems alike. The stability argument that legitimately governs how to patch a critical-care medical device has no business governing how quickly you respond to an actively exploited RCE on a public-facing authentication portal.
Stability concerns should govern the mechanics of patching: testing procedures, rollback plans, maintenance windows, notification chains. They should not function as a reason to deprioritize a finding that belongs in your urgent queue. When those two things get conflated, you end up with an exception backlog that grows indefinitely and a patch program that looks rigorous on paper while leaving reachable systems exposed for months.
A Workable Prioritization Model
The recommendation here is concrete: retire CVSS as your primary filter and replace it with a three-variable model.
Exploitability evidence. Is there active exploitation in the wild? Is the vulnerability on CISA’s Known Exploited Vulnerabilities catalog? Does it have a high Exploit Prediction Scoring System (EPSS) score, which measures the probability of exploitation within 30 days based on real-world data? These signals are a more accurate proxy for attacker interest than theoretical severity ratings.
Asset reachability. Is the affected system internet-facing? Is it reachable from a compromised endpoint without additional privilege escalation? Can an attacker with initial access reach it through a standard lateral movement path? Reachability determines whether a vulnerability is a live threat or a theoretical one.
Asset value. What does a successful compromise of this system enable? Does it hold credentials that provide access to other systems? Does it process sensitive data? Does it sit adjacent to your most critical infrastructure? A vulnerability on a low-value isolated system with no exploitation evidence in the wild can wait. The same vulnerability on a system adjacent to your domain controllers cannot.
A medium-CVSS vulnerability on an internet-facing system with active exploitation and a public proof-of-concept should be treated as more urgent than a critical-CVSS finding on an air-gapped internal server with no known exploit activity. That is not an edge case. That is the standard operating condition for most enterprise environments.
While patches are pending, compensating controls are not optional. Network segmentation limits blast radius. Enhanced logging and monitoring creates detection opportunity. Restricting access to affected systems reduces the pool of potential attackers. These are not substitutes for patching, but they are the difference between a vulnerability that is unpatched and one that is unpatched and completely exposed.
On exception management: every patch program has an exception backlog. Almost none of them are systematically reviewed. Set a review cadence, require reauthorization on a defined schedule, and make the residual risk explicit to the person accepting it. Exceptions that live forever are not exceptions. They are permanent policy decisions being made by inaction.
What Offensive Testing Actually Finds
Red team engagements consistently reveal a pattern worth naming. Organizations rarely fail because they missed a critical CVE on a high-visibility, heavily monitored system. They fail because lateral movement paths run through less-monitored internal systems, exception backlogs that have not been reviewed in 18 months, and legacy infrastructure that compliance frameworks do not require testing.
Patch compliance metrics look strong on paper. The attack path runs through what the metric did not measure. A CVSS-sorted patch queue tells you what your scanner found and how the findings are rated. It does not tell you which of those findings sit on the path an attacker would actually use to reach your most valuable systems. That is the visibility gap offensive assessments are designed to expose.
The Recommendation
The speed versus stability versus security framing presents a false choice. It is not a three-way tie between competing goods. It is a sequencing problem.
Apply urgency where exploitability evidence is high and asset exposure is real. Apply caution where operational risk from the patch itself is genuine and attacker reachability is limited. Build a systematic process for everything in between, and review it on a schedule.
Organizations that patch deliberately, with visibility into what is actually reachable and what attackers are actually exploiting, are materially harder targets than those chasing theoretical severity scores. The tools to build that program are already available. CISA’s KEV catalog is public. EPSS scores are free. Asset inventory and network segmentation data is something your team has or should have.
The dilemma resolves when you stop patching against a score and start patching against how an attacker actually thinks.
Satine Technologies is a service-disabled veteran-owned offensive cybersecurity firm founded by former NSA and U.S. Cyber Command operators. We help organizations understand their security from an attacker’s perspective.
References
Wikipedia / FIRST, “Common Vulnerability Scoring System”: https://en.wikipedia.org/wiki/Common_Vulnerability_Scoring_System
VulnCheck, “2024 Trends in Vulnerability Exploitation” (February 2025): https://vulncheck.com/blog/2024-exploitation-trends
VulnCheck, “State of Exploitation: A Look Into 1H-2025 Vulnerability Exploitation” (July 2025): https://vulncheck.com/blog/state-of-exploitation-1h-2025
Akamai Security Intelligence Response Team, “CVE-2024-4577 Exploits in the Wild One Day After Disclosure” (July 2024): https://www.akamai.com/blog/security-research/2024-php-exploit-cve-one-day-after-disclosure
Apache Software Foundation, “MEDIA ALERT: The Apache Software Foundation Confirms Equifax Data Breach Due to Failure to Install Patches Provided for Apache Struts Exploit” (September 2017): https://news.apache.org/foundation/entry/media-alert-the-apache-software
CSO Online, “Equifax Data Breach FAQ: What Happened, Who Was Affected, What Was the Impact?” (updated 2025): https://www.csoonline.com/article/567833/equifax-data-breach-faq-what-happened-who-was-affected-what-was-the-impact.html
Sophos X-Ops, “Prioritizing Patching: A Deep Dive into Frameworks and Tools, Part 1: CVSS” (December 2024): https://news.sophos.com/en-us/2024/12/27/prioritizing-patching-a-deep-dive-into-frameworks-and-tools-part-1-cvss
Picus Security, “Vulnerability Prioritization in 2026: Why CVSS Isn’t Enough”: https://www.picussecurity.com/resource/blog/vulnerability-prioritization-why-cvss-isnt-enough
Maze, “2025: The Year Vulnerabilities Broke Every Record” (2026): https://mazehq.com/blog/2025-wrapped-the-year-vulnerabilities-broke-every-record