CVE-2026-59310: VMware vCenter Flaw Actively Abused for Persistence

Published on 13 August 2026

Five days. That's how long it took for attackers to compromise the first vulnerable systems after the public disclosure of a critical VMware flaw. On 29 July 2026, Broadcom published the security advisory for CVE-2026-59310 – and by 3 August, security researchers were already observing the first contacts between compromised systems and the attackers' infrastructure. As many as 361 affected IP addresses in 47 countries have now been documented, and Germany is among the five most heavily affected countries.

If your company uses VMware vCenter – whether operated in-house or through a service provider – then this article is highly relevant to you. The flaw allows attackers to execute arbitrary code on one of the most central components of your IT infrastructure without any prior authentication. And it is already being actively exploited.

What happened?

Broadcom, owner of the VMware products since acquiring the company, disclosed a critical vulnerability in vCenter Server with advisory VMSA-2026-0006 (updated to VMSA-2026-0006.1 on 3 August). VMware vCenter is the central management layer for vSphere environments – in other words, the software administrators use to control their entire virtualised server and data-centre infrastructure.

The flaw carries the identifier CVE-2026-59310 and a CVSS score of 9.8 out of 10 – nearly the maximum, denoting "critical". Specifically, it is what is known as a directory-traversal vulnerability (technical term CWE-22), that is, a flaw in the restriction of file paths. It resides in vCenter's Syslog server, which is only supposed to receive log data.

The crucial point: Broadcom states unambiguously what an attacker can do with it:

"A malicious actor with network access to vCenter may exploit this issue to execute arbitrary code."
– Broadcom VMware, VMSA-2026-0006.1

In other words: an attacker with network access to the vCenter server can execute arbitrary code. According to the CVSS vector (AV:N/AC:L/PR:N/UI:N), no prior authentication is required, the attack is possible over the network, is technically low in complexity and requires no interaction from the victim. That is the most dangerous combination imaginable.

The observed attack chain: first the breach, then persistent access

The threat research team QUIRSO has documented an active campaign against internet-reachable vCenter systems following an incident response investigation. The sequence, according to their findings, looks like this:

1. The attacker uses the path traversal flaw for initial access.
2. A malicious cronjob is then set up – a scheduled automation mechanism under Linux that repeatedly executes commands.
3. This cronjob launches the tool reverse_ssh, which maintains persistent outbound remote access.

The trick with the "outbound" access is insidious: many firewalls strictly block incoming connections but generously permit outgoing ones. This way, the attacker stays connected without triggering a classic alarm. An important point of context: reverse_ssh is a legitimate open-source tool. QUIRSO explicitly warns against treating its mere presence as evidence:

"The presence of reverse_ssh should not, by itself, be treated as proof of malicious activity."
– QUIRSO Threat Research

A finding must therefore be correlated with further indicators – unauthorised installation, unexpected outbound connections, execution on a vulnerable vCenter appliance.

How serious is the situation really?

Active exploitation has been confirmed by several independent bodies. The NHS England National CSOC (the cyber security centre of the British health system) escalated its warning to high severity on 12 August 2026 and reported observed exploitation with reverse-SSH persistence. Its assessment is unambiguous:

"The NHS England National CSOC assesses further exploitation as likely."
– NHS England National CSOC

QUIRSO also points to an alarming pattern – the close temporal coupling of disclosure and attack:

"The strong correlation between the time of disclosure and exploitation suggests the disclosure as the initial starting point for the campaign."
– QUIRSO Threat Research

In other words: the attackers apparently used the publication of the advisory as a starting signal and struck en masse within just a few days. By 5 August, around 95 percent of the 361 victim IP addresses later identified had already appeared.

An important note on the figures: the 361 IP addresses are explicitly not a count of affected companies, and certainly not a count of affected data records. IP addresses can represent hosting, cloud or shared infrastructure. Of the 361 addresses, 185 were located in the five most heavily affected countries: Germany, the USA, Turkey, Iran and France. An exact German figure was not published – but it is clear that Germany is among the leading group.

One further note: as retrieved on 12 August 2026, CVE-2026-59310 was not listed in the official CISA KEV catalogue (the US register of known exploited vulnerabilities). That, however, is no counter-evidence – the observations documented by QUIRSO and NHS England remain unaffected. A public proof-of-concept (that is, ready-made example exploit code) was likewise not confirmed in the sources reviewed.

Who is affected?

Affected are not only standalone vCenter installations, but also vCenter as a component of the following products:

• VMware Cloud Foundation
• vSphere Foundation
• Telco Cloud Platform / Telco Cloud Infrastructure

For German SMEs, the flaw is immediately relevant if they operate vCenter themselves or use it through a service provider for their website, shop, server or other company infrastructure. An ordinary website without vCenter is not directly vulnerable to this specific CVE. But beware: your website's availability and the data it processes may be indirectly at risk if the underlying virtual infrastructure is managed via an unpatched vCenter. So actively ask your hosting or managed service provider.

How to check whether you are affected

1. Create an inventory: Record all VMware products and their operators – your own data centre, managed service provider, hosting or cloud provider. Explicitly ask whether vCenter is in use as a component of Cloud Foundation, vSphere Foundation or Telco Cloud.
2. Determine the server build: Establish the actual vCenter server build on each appliance. For this, Broadcom cites the command vpxd -v on the appliance or the overview page of the management interface at https://<VC_FQDN>:5480. Do not rely solely on the version display in the vSphere Client – according to Broadcom, this can deviate from the actual server build.
3. Compare against the matrix: Compare the build and product branch with the response matrix in VMSA-2026-0006.1. In particular, the following are considered insufficient: 9.1.x.x before 9.1.0.0300, 9.0.x.x before 9.0.2.0100 and 8.0 without the fix designated for the respective branch.
4. Check reachability: Determine whether the vCenter management access is reachable from the internet or from broad internal networks. However, merely restricting reachability does not replace the patch.
5. Check for compromise: Because of the confirmed exploitation, IT, SOC or incident response teams should look for unauthorised cronjobs, unexpected reverse_ssh installations, unusual outbound connections and the execution of reverse_ssh on vulnerable vCenter appliances. QUIRSO provides a generic YARA rule as an investigative starting point – a match alone is not yet proof of an attack.
6. Document: Record findings, identified data processing activities and all indicators in an audit-proof manner. If there are signs of a compromise, qualified incident response and data protection specialists should take over the further assessment.

What you need to do now, concretely

Broadcom cites no workaround for CVE-2026-59310. Applying the updates is the only effective remedy. The patches have been available since 29 July 2026 and are cumulative.

The specific fixed versions (per VMSA-2026-0006.1):

• vCenter 9.1.x.x → 9.1.0.0300
• vCenter 9.0.x.x → 9.0.2.0100
• vCenter 8.0 per branch → 8.0 U3k or 8.0 U2f
• VMware Cloud Foundation 5.x → asynchronous patch to vCenter 8.0 U3k
• Telco Cloud Platform/Infrastructure → see Broadcom KB449886

Your steps:

1. Patch immediately: Prioritise the appropriate Broadcom update within a controlled emergency or change process. Choose the fixed version exclusively via the Broadcom response matrix for your specific product branch.
2. Don't skip preparation: Before updating, check backups, restorability, dependencies and the patch path envisaged by the vendor.
3. Restrict access: Move vCenter into a dedicated management network for authorised administrators. In particular, remove direct internet reachability if it is not operationally essential. Rapid7 warns, however: internal reachability does not preclude an attack if an attacker already has network access.
4. Increase monitoring: Until the patch is fully applied and during the follow-up review, keep a closer watch on vCenter, the cron configuration, outbound SSH connections and suspicious binaries.
5. Treat suspicion as an incident: Signs of successful exploitation constitute a security incident. Containment, evidence preservation and forensic investigation must be planned in parallel with restoration. The Belgian National Cybersecurity Centre emphasises: a patch only protects against future exploitation and does not eliminate a compromise that has already occurred.

GDPR: What you need to consider

The vulnerability alone does not trigger a GDPR notification obligation. However, if your investigation reveals a breach of the protection of personal data – for instance through unauthorised access, disclosure, alteration or loss – you as the controller must assess the risk to the rights and freedoms of the individuals concerned.

If a risk is likely to exist, the competent supervisory authority must be informed under Art. 33(1) GDPR without undue delay and, where feasible, within 72 hours of becoming aware; any later notification must be justified. Where a high risk is likely, the affected individuals must also, as a rule, be notified under Art. 34 GDPR. Every data breach must be documented under Art. 33(5) GDPR.

Art. 32 GDPR requires risk-appropriate technical and organisational measures – and timely patching is part of that. In the event of violations, Art. 83(4) GDPR provides for fines of up to €10 million or 2 percent of worldwide annual turnover, whichever is higher. For context: in 2019, the German BfDI imposed a fine of €9.55 million on 1&1 Telecom over what it considered inadequate security measures. That case does not concern a VMware flaw and allows no prognosis of fines – but it does show that supervisory authorities take a lack of technical precautions seriously.

This does not constitute legal advice for individual cases. Whether obligations exist, and which ones, depends on the actual processing operations and the specific risk assessment.

Conclusion

CVE-2026-59310 is the worst-case scenario security officers dread: a critical flaw (CVSS 9.8) in a central infrastructure component, exploitable over the network without authentication, with confirmed active exploitation within days of disclosure – and Germany right in the middle of it. Using a cronjob and reverse_ssh, the attackers are deliberately setting themselves up for persistent access.

If you operate vCenter, or have it operated for you, the rule is: patch to the appropriate fixed version immediately, restrict management access and additionally carry out a compromise check – because a patch alone does not remove a breach that has already occurred. If you don't manage vCenter yourself, clarify without delay with your service provider whether and when patching was done. The five days until the first attack show one thing: with this flaw, every day counts.