Why Attackers Are Betting You'll Sleep On Patching
Shane O’Donnell, Centric Consulting’s Vice President of Cybersecurity, has two decades of experience in audit and cyber risk management.
gettyNine hundred seventy-four. That’s how many vulnerabilities Microsoft patched in a single record-breaking update, including two zero-days already being exploited before the fix shipped. Researchers point to AI-assisted vulnerability discovery as the driver, suggesting that a batch this size won’t remain unusual for long.
In addition to growing volume, exploitation has also gotten faster. A vulnerability disclosed in 2023 took an average of five days to weaponize, according to Cloud Security Alliance research. By last year, nearly a third of newly tracked exploits appeared on or before the vulnerability’s public disclosure date, and that window keeps closing. AI tools can now write working proof of concept (PoC) exploit code for a newly disclosed CVE in 10 to 15 minutes for about a dollar, the report notes.
We are already seeing what happens when patching falls behind in this environment.
In December 2025, a critical flaw in the open-source React framework’s server-side components, which rated a max 10.0 on severity, was disclosed and patched the same day, and attackers were exploiting unpatched instances within 48 hours. Three months after the fix had shipped, LexisNexis Legal & Professional confirmed a breach tied to the vulnerability.
That failure isn’t limited to what a scanner catches or to attacks in progress. In another incident, a security researcher found flaws in Frontier Airlines’ booking system through manual testing, no exploitation or breach necessary, and reported them directly to the company. Personal information like passport numbers, home addresses and partial credit card data were being leaked through boarding pass information. Frontier didn’t act until the researcher went public over 100 days later, and one of the exposures was reportedly still live days after the airline said it was fixed.
Most vulnerability management programs were built for the slower pre-AI timeline, one where a monthly patch cycle and a few weeks of compatibility testing counted as diligence.
Underneath that timeline problem, most programs are quietly running one of two models: In the first, scanning tools flag issues, someone forwards a report and remediation depends on whoever happens to pick it up; in the second, closing a finding is a managed, ongoing responsibility with an owner, a timeline and a review cadence. The tool feeds a program instead of standing in for one.
A 2026 Adaptiva survey found 74% of organizations call coordinating vulnerability prioritization and remediation their single biggest security issue, and just 8% have reached full patching automation, even though 90% plan to expand it.
In other words, plenty of companies paid for the second model and are still operating the first.
• How much of last quarter’s unplanned work started as a vulnerability finding? If remediation nobody planned for shows up as a fire drill instead of scheduled work, those fire drills will cost more than what shows up on a security budget line.
• How many critical vulnerabilities are open right now, and how old is the oldest one? Programs report the first number constantly and the second one rarely, even though age is what gets exploited. A critical vulnerability open for 90 days has been an open door for 90 days.
• What happens between a critical disclosure and an assigned ticket? In plenty of organizations, that path runs through two or three approvals before anyone owns the fix. Every handoff costs a day that the exploit doesn’t need.
• How much of your scanning platform’s licensed capability is turned on and configured, not just paid for? Most organizations set coverage up once, years ago, and never finished the job.
• Which environments sit outside standard scanning? Look at cloud workloads, recently acquired systems and anything stood up outside the normal build process. Acquisitions and cloud sprawl outdate an asset inventory faster than most teams update it.
• What path would a patch take if it had to ship this week instead of at the next maintenance window? If the honest answer is your normal change process, there is no emergency lane. There’s one speed, and it belongs to whomever runs the slowest change-control meeting on your calendar.
Pull your ticketing system this week, sort open vulnerabilities by age instead of severity and then look at how long the oldest one has been sitting there.
After seeing the open vulnerabilities, check whether the scan that flagged those findings has full coverage and is configured the way it should be. A clean list from a scanner with blind spots isn’t the same as a clean environment. Cross-check the oldest ones against CISA’s Known Exploited Vulnerabilities catalog and each one’s Exploit Prediction Scoring System (EPSS) score. Any that appear in CISA’s catalog have already moved from theoretical risk to active exploitation.
Then find the last critical disclosure your team handled and time how many days passed before a person owned it. If that path runs through your standard change process, get your security and change-management teams to agree on an expedited lane for security-critical patches before the next one hits, not while you’re in the middle of it.
The vulnerabilities that end up in a breach report are rarely secret. They sat in a ticketing system, assigned to someone, waiting on a maintenance window that kept expanding. That list is likely sitting in your system right now, and every day it ages is a day handed to whomever finds it first.
Forbes Technology Council is an invitation-only community for world-class CIOs, CTOs and technology executives. Do I qualify?
