Why VMware and SAP show that patch cadence alone is not a security strategy
In a recent post, I wrote about a security incident where the availability of a patch would not necessarily have prevented the compromise.
Recent VMware and SAP vulnerabilities provide the other half of that argument.
| The patches existed. The attackers came anyway. |
SAP released its August security fixes on August 11, including CVE-2026-58231, a maximum-severity vulnerability in SAP Commerce Cloud’s Data Hub Adapter. By August 14, researchers were seeing exploitation attempts hit honeypots.
Three days.
Broadcom disclosed CVE-2026-59310, a critical 9.8-rated vulnerability in VMware vCenter, on July 29. Researchers observed compromised systems connecting to attacker infrastructure on August 3.
Five days.
Within days, the VMware story became worse. Follow-on incident-response analysis described attackers obtaining root-level execution on the vCenter Server Appliance, establishing multiple forms of persistence, creating vSphere administrator accounts, reaching ESXi hosts, and, in at least one investigated environment, deploying Babuk-derived ransomware against ESXi.
The lesson is not simply to patch faster. Patching remains essential, but a complete security strategy also needs to reduce exposure before a patch is deployed, detect attackers who arrive first, contain the damage, and support recovery.
Why Isn’t Faster Patching Enough?
There is an obvious response to incidents like these: organizations need to patch faster.
Where organizations have access to the vendor fix, they should evaluate and deploy it as rapidly as they safely can.
But that answer becomes less useful with every day that disappears from the interval between disclosure and exploitation.
Enterprise infrastructure does not exist in a laboratory. Updates have to be identified, assessed for applicability, downloaded, tested against complex environments and dependencies, approved through change processes, scheduled around operational requirements, deployed, and then validated.
Those processes exist for a reason. A hastily deployed update that causes an outage, breaks dependencies, or removes critical management capability is not generally considered a security success.
Attackers have rather fewer governance requirements.
And the asymmetry is not theoretical.
VulnCheck’s analysis of the first half of 2026 found that 23.43% of known exploited vulnerabilities showed evidence of exploitation on or before the day the CVE was published. For those vulnerabilities, there was no meaningful patch window at all.
Automation can compress the race further. Patch diffing, vulnerability research, scanning, and exploit development were automatable long before generative AI. AI-assisted analysis may accelerate parts of that workflow, but we do not need to speculate about its exact role to see the underlying trend: defenders increasingly have to make decisions on a clock measured in days, and sometimes hours.
| At some point, telling organizations simply to patch faster becomes the cybersecurity equivalent of telling someone to outrun the bullet. |
What Happens When an Attacker Exploits a Vulnerability Before You Patch It?
The VMware incident illustrates an even more important problem.
Researchers observed attackers establishing persistent outbound access using reverse SSH and other backdoor mechanisms.
At that point, there are two separate problems.
The first is the vulnerability.
The second is the attacker.
Installing the patch deals with the first. It does not necessarily deal with the second.
An old saying describes the problem neatly: shutting the stable door after the horse has bolted. The door still needs to be shut, but once exploitation has occurred, the problem has changed. Defenders now have to determine where the attacker went and what they did after getting in.
That distinction is routinely lost in vulnerability-management conversations. A scanner turns green after remediation and the organization records the risk as closed. Meanwhile, an attacker who exploited the vulnerability yesterday may have created accounts, stolen credentials, established persistence, changed trust relationships, moved laterally, or simply found another route back in.
| The patch can close the original door. It cannot tell you who walked through it before you arrived. And it cannot tell you whether they copied the keys. |
VMware makes that distinction particularly important because vCenter is not just another application server. It is part of the control plane for the virtual infrastructure. It exists to see, coordinate, and administer large portions of the environment.
In the investigated campaign, attackers did exactly what defenders should worry about after control-plane compromise: they created administrative access, used vSphere capabilities for discovery, reached ESXi hosts, and ultimately used that position to deploy ransomware in at least one analyzed environment.
That is a blast-radius problem, not merely a patching problem.
Once a management plane is compromised, the investigation cannot stop at the vulnerable appliance. Defenders need to know which identities were exposed, which privileges changed, which hosts were touched, what administrative operations occurred, and whether another path into the environment was established.
The uncomfortable limit of patching
None of this is an argument against patching.
Where an organization has access to a vendor remediation, it should be evaluated and deployed as quickly as the environment can safely support. Where a vendor remediation path is unavailable, the risk still has to be managed.
The mistake is asking a single preventive control to carry the weight of an entire security strategy.
Broadcom’s own guidance for the July VMware advisory makes the distinction useful. It lists no product workaround for CVE-2026-59310. However, organizations may still have mitigations and compensating controls available through their security posture, perimeter and appliance firewalls, and defense-in-depth architecture.
That is the real question: what protects the organization during the three days, five days, or eventually perhaps three hours between vulnerability disclosure and exploitation?
| What Should a Resilient Security Architecture Be Able to Do? A resilient security architecture should be able to reduce exposure, detect exploitation and persistence, contain a compromised management plane, and recover if other controls fail. The practical questions include: · Can the vulnerable service be isolated or its exposure reduced? · For VMware, can vCenter be restricted to tightly controlled management networks and approved administrative paths rather than broadly reachable networks? · Can unnecessary outbound connectivity from management appliances be constrained? A reverse-SSH mechanism depends on the compromised system being able to establish the outbound control channel. Should a vCenter appliance be able to initiate arbitrary Internet connections, and would anyone notice if it suddenly did? · Can exploit attempts be detected? · Would the creation of a new vSphere administrator, a new local ESXi account, unexpected cron activity, unusual API discovery, or an outbound connection from a management appliance generate an alert? · Can an attacker establish persistence without somebody noticing? · If a management plane is compromised, can that compromise be contained before it becomes control of the infrastructure it manages? · And if prevention and containment both fail, can the organization recover?
|
Does Vendor Support Status Mean Software Is Secure?
No. Vendor support status affects the remediation options available to an organization, but it does not describe the security state of the environment.
For years, vendor support status has often been used as a rough proxy for security. Supported software generally has a vendor remediation path. Unsupported software may have a limited, different, or nonexistent one.
That distinction matters.
It just does not describe the security state of the environment.
The VMware and SAP systems involved here had vendor fixes available. That clearly mattered, but it did not eliminate the exposure. Organizations still had to identify applicability, make an operational decision, deploy the remediation, and do so before attackers arrived.
And if exploitation happened first, they needed a completely different set of capabilities to determine whether they had been compromised and to remove the attacker.
The same principle works in the opposite direction.
The VMware and SAP systems involved here had vendor fixes available. That clearly mattered, but it did not eliminate the exposure. Organizations still had to identify applicability, make an operational decision, deploy the remediation, and do so before attackers arrived.
And if exploitation happened first, they needed a completely different set of capabilities to determine whether they had been compromised and remove the attacker.
Likewise, the existence of a patch does not mean the system is secure.
| Patch availability is not a security state. |
How Do You Build Cyber Resilience Beyond Patching?
Security architecture needs to be designed around the assumption that prevention will occasionally fail.
Use vendor remediation where it is available. Harden systems. Reduce unnecessary exposure. Apply compensating controls where code-level remediation cannot happen immediately or is unavailable.
But build detection capable of identifying the attack that gets through anyway.
Treat management infrastructure as its own security tier. A vCenter server, domain controller, backup platform, or privileged-access system should not inherit the same network trust assumptions as the workloads it manages.
Design containment so that one compromised system does not automatically become an enterprise-wide incident.
Maintain recovery capabilities for the day when both prevention and containment fail.
That is the difference between building an environment around patch compliance and building one around resilience.
Three days from patch availability to exploitation attempts should concern every CISO responsible for SAP.
Five days from disclosure to observed VMware compromise should concern everyone responsible for virtual infrastructure.
But the numbers themselves are not really the story.
The story is that the attackers’ clock is getting faster, and eventually, they are going to beat yours.
| The objective was never to win every race to the patch. It was to make sure losing one does not mean losing the business. |
