Every advisory this month has arrived faster than the last one got fixed. Cisco gave defenders one day between disclosure and CISA’s remediation deadline for a firewall flaw already under active exploitation. SAP’s Commerce Cloud fix was reverse-engineered and weaponized in three days. A researcher’s SQL injection disclosure in GeoTools drew hundreds of exploitation attempts against internet-facing GeoServer instances before a patch even existed. I keep hearing the same conclusion drawn from numbers like these: that vendors and CISA are getting faster, and faster patching is the fix. I think that reading gets the lesson backward.
The Case for “We’re Getting Faster”
The optimistic version of this story is not unreasonable. CISA’s Known Exploited Vulnerabilities catalog and its aggressive remediation deadlines exist precisely to compress the window attackers have to act, and on the evidence, they are working as intended: Cisco’s firewall advisory carried a one-day federal remediation deadline because the flaw was confirmed exploited before the advisory even shipped, which is the system catching a live threat in near real time, not failing to. Vendors are shipping same-day hotfixes. Researchers are disclosing responsibly and vendors are patching within days, not the months-long silences that used to be normal. By that measure, 2026 looks like a genuine improvement over how this industry used to operate.
Why Speed Alone Isn’t the Point
The problem with crediting speed as the fix is that every one of the cases above shows attackers matching or beating the defenders’ timeline, not losing to it. SAP’s maximum-severity Commerce Cloud flaw was patched on August 11 and under active exploitation by August 14, three days, which is fast by any historical standard and still nowhere near fast enough to matter for an unpatched instance. GeoServer’s SQL injection flaw was being probed within hours of public disclosure, before GeoTools maintainers had shipped a fix at all. And N-able’s first patch for an N-central authentication bypass left a second exploitation path standing, one attackers found and used within days of the original fix going public, effectively using the patch itself as a map to what remained broken.
Media Partner
The vCenter case now unfolding is the clearest version of this. Broadcom patched two critical, unauthenticated vCenter flaws on July 29. Mass opportunistic exploitation followed within about five days, the kind of speed that looks like the system working. What the trade press has only now surfaced is a second, quieter operation: a suspected nation-state actor that used the same window to build persistent backdoors and, weeks later, deploy ransomware directly on ESXi hosts. The fast, visible attack and the slow, dangerous one both exploited the identical flaw. Patch velocity did nothing to stop either, because velocity was never the variable that mattered for a vulnerability with no available workaround and a large, internet-facing attack surface.
What Actually Has to Change
Grading vulnerability management on how many days elapse between disclosure and patch treats every flaw as a race that ends the moment the fix ships. It does not. A patch closes the door; it says nothing about who already has a key. None of the incidents above were caught by patch speed. They were caught, when they were caught, by monitoring for post-compromise indicators, unauthorized admin accounts, backdoor processes disguised as legitimate services, exploitation attempts logged before a fix existed, the unglamorous work that happens after the advisory, not the sprint to publish one.
I am not arguing against fast patching. Fast patching is table stakes now, and any organization not treating a nine-point-something CVSS score with an active exploitation report as a same-day event is behind. My argument is narrower: stop measuring program maturity by patch velocity alone, and start measuring it by whether a compromise assessment automatically follows every critical, internet-facing vulnerability with a documented pre-patch exploitation window, regardless of how quickly that vulnerability was ultimately fixed. Security leaders who can answer “did we patch it” but not “did we check whether someone got in before we did” are grading themselves on the part of this problem that attackers have already learned to route around.
In practice, that means building a second workflow alongside patch management, one that triggers automatically rather than waiting for a suspicious ticket. Any critical, unauthenticated, internet-reachable vulnerability with a reported pre-patch exploitation window should open a standing compromise-assessment task the moment the patch ships, not a discretionary one a SOC analyst has to remember to file. That task should stay open for weeks, checking for the unauthorized accounts, backdoor processes and anomalous outbound connections that patch verification alone will never surface, rather than closing the moment a vulnerability scanner confirms the fix is installed. It is slower, less satisfying to report up the chain than a green patch-compliance dashboard, and it is the part of the response that actually catches the attacker who was already inside before the fix landed.
Anil Kale covers vulnerabilities and the business of security for CyberTech.
Source: Broadcom Security Advisory
