Critical vCenter Flaw CVE-2026-59310 Actively Exploited

Published on 17 August 2026

Five calendar days. That's how long it took, after the release of a VMware security update, for the first compromised servers to start reaching out to their attackers. On 29 July 2026, Broadcom made available a patch for a critical vulnerability in vCenter Server – and by 3 August 2026, the first hijacked systems were already establishing outbound connections to attacker infrastructure. Security researchers are now documenting an active attack campaign affecting hundreds of IP addresses worldwide, and Germany is among the five most affected countries.

If you run VMware vCenter yourself, or your hosting or IT service provider uses this software for your systems, you should act now. In this article, we explain in plain terms what happened, how to check whether you are affected, and what specifically you need to do.

What happened?

The vulnerability is identified as CVE-2026-59310 (CVE stands for "Common Vulnerabilities and Exposures" – a globally unique identifier for security flaws). It resides in the so-called syslog server of VMware vCenter. vCenter is the central management software companies use to control their virtual servers and data centres – essentially the command centre of a VMware environment.

Broadcom, the maker of VMware, classifies the flaw as critical and rates it with a CVSS score of 9.8 out of a possible 10. CVSS ("Common Vulnerability Scoring System") is a standardised system for assessing the severity of vulnerabilities; scores of 9.0 and above are considered critical. The official scoring vector describes an attack that is carried out over the network, is technically straightforward to execute, and requires neither prior authentication nor user interaction.

Broadcom summarises the danger clearly in security advisory VMSA-2026-0006.1:

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

Translated: an attacker with network access to vCenter can exploit the flaw to execute arbitrary program code. In the worst case, this means a complete takeover of the management layer – and thus potential control over the entire virtualised environment.

The technical background – explained simply

CVE-2026-59310 is a so-called directory traversal vulnerability. Directory traversal means that a flaw allows improper navigation through file paths and directories – in other words, reaching places that should actually be off-limits. In this specific case, according to Broadcom, the problem lies in the vCenter syslog server, which is only supposed to process log data.

An important distinction: "network access" is not automatically the same as "internet access". However, vCenter systems that are publicly reachable from the internet significantly increase the attack surface – and it is precisely such systems that the observed campaign targets.

The observed attack chain

The security research team QUIRSO documented the course of an attack from a specific incident response case (i.e. the response to a real security incident). These were not merely harmless scans: the researchers found path traversal activity, followed by the installation of reverse_ssh.

reverse_ssh is an open-source tool that establishes a so-called reverse shell over SSH – in simple terms, an outbound remote access channel. With it, attackers establish a connection from the hijacked machine outward to their own infrastructure, thereby securing persistent access (persistence). The tool is also used legitimately in security testing – so a single finding is not proof on its own. QUIRSO puts it in context:

"The presence of reverse_ssh should not, by itself, be treated as proof of malicious activity. In combination with unauthorized installation, unexpected outbound connections or execution on a vulnerable vCenter appliance, however, it is a high-priority indicator requiring investigation." – QUIRSO Threat Research Team

The Shadowserver Foundation, a non-profit security organisation, however, assumes full compromise for the systems listed in its special report:

"the reverse_ssh persistence mechanism has been deployed by the attackers on all victims reported, and they should be considered fully compromised." – The Shadowserver Foundation

To put the threat situation in context: at the time of Rapid7's analysis on 30 July 2026, there was still no known public proof-of-concept (a freely available example code demonstrating the exploitation). However, this statement was time-limited – a few days later, active exploitation was a reality. For defenders, what matters is not the existence of a PoC anyway, but the confirmed real-world compromise.

Who is affected?

QUIRSO recorded 361 unique victim IP addresses across 47 countries. It is important to interpret this figure correctly. QUIRSO explicitly clarifies:

"The exact number of victim organizations cannot be inferred from these IP addresses, as an IP address does not necessarily correspond to a unique company or physical system." – QUIRSO Threat Research Team

So 361 IP addresses do not mean 361 companies or 361 physical servers. The figure must not be oversimplified. What is clear, however: 185 of these IP addresses – slightly more than half – together fell to Germany, the USA, Turkey, Iran and France. Germany is thus among the most affected countries. A separate, reliable figure for Germany, however, was not published in the source examined.

The campaign's dynamics were high: on 4 August 2026, 151 new victim IP addresses were added in a single day. By 5 August, 343 of the 361 IP addresses – around 95 percent – were already visible. The BSI (Germany's Federal Office for Information Security) added the note "active exploitation reported" to its warning WID-SEC-W-2026-2569 on 10 August.

What does this mean for small and medium-sized businesses?

The vulnerability is only directly relevant to you if you run VMware vCenter yourself, or if your hosting, managed service or cloud provider (IaaS – "Infrastructure as a Service") uses this component to deliver your website or the underlying systems.

If you run an ordinary website without operating vCenter yourself, you are not directly affected by this particular CVE. You do, however, carry a supply chain and availability risk if your service provider uses vCenter. That's why, in this case, it's worth asking your provider directly.

How to check whether you are affected

1. Take inventory: Draw up a list of all vCenter instances as well as the teams and service providers operating them. Check whether vCenter is operated standalone or runs as part of VMware Cloud Foundation, vSphere Foundation, Telco Cloud Platform or Telco Cloud Infrastructure.
2. Determine the version: Log in exclusively via the regular administration route. According to Broadcom, the build and version are shown on the "Summary" tab in the vSphere Client. Alternatively, an authorised administrator can check the variables $global:DefaultVIServer.Build and $global:DefaultVIServer.Version in PowerCLI after Connect-VIServer.
3. Compare against the fix matrix: The patched versions are 9.1.0.0300 for 9.1.x, 9.0.2.0100 for 9.0.x, and 8.0 U3k or 8.0 U2f for the respective vCenter 8.0 branch. Any older version within the relevant branch is considered affected. In case of doubt, Broadcom recommends assuming you are affected and acting immediately.
4. Check reachability: Using your firewall, NAT, VPN and asset inventory data, verify whether the vCenter management interface is reachable from the internet. Do not scan systems belonging to others. Any public exposure of your own environment must be removed immediately or restricted to strictly controlled access.
5. Search for indicators of compromise: Search the vCenter appliance and the central security and network logs for unauthorised reverse_ssh installation, unexpected outbound connections, unusual execution and path traversal indicators. QUIRSO provides a generic YARA rule (a detection pattern for malware) for reverse_ssh; any hit should always be correlated with further contextual data.
6. In case of findings: assume an incident: If reverse_ssh or matching indicators are found, do not treat the instance as merely "patched", but as a possible security incident. Arrange a qualified forensic investigation and, if necessary, bring in incident response support.

What you need to do now

1. Apply the emergency update: Initiate an emergency change and install the appropriate Broadcom fix without delay. Broadcom explicitly classifies the situation as an ITIL emergency change because no workaround is available. The patches are cumulative – a single update contains all updates available for the respective product branch. The update runs via the standard procedures, such as the vCenter VAMI. The vSphere Client is briefly unavailable during the update; according to the vendor, however, running virtual machines and container workloads continue to operate.
2. Reduce the attack surface: Until the update is fully applied, block public reachability of the vCenter management and use only a segregated management access. Broadcom points out that firewalls can only be compensating controls – they do not replace the update.
3. Check compatibility: Before updating, check the compatibility of vCenter, ESX and, where applicable, vSAN in the Broadcom interoperability matrix. For VMware Cloud Foundation 5.x, the documented asynchronous patch process must be used. For certified third-party systems such as VxRail or HPE SimpliVity, only their approved patch procedures apply.
4. Monitor and investigate: Pay particular attention to unauthorised reverse_ssh builds, unexpected outbound remote access connections and unusual execution on the vCenter appliance – always in context, because reverse_ssh can also be used legitimately.
5. If suspicious: start the incident process: Restrict access according to your incident response procedure, secure the logs and evidence needed for analysis, have the scope and impact investigated, and document the decisions. Remember: patching alone does not remove remote access that has already been set up.
6. Hold service providers accountable: If an IT service provider operates vCenter for your website or backend systems, request in writing the product branch in use, the patch version, confirmation of the absence of public reachability, the check for indicators of compromise, and inclusion in the data protection incident process.

GDPR context: when does an incident become reportable?

An exploitable vulnerability alone does not trigger a reporting obligation – what matters is the specific incident, not the CVSS score or the patch status. The Independent State Centre for Data Protection Schleswig-Holstein (ULD) defines a data breach as the destruction, loss, alteration, unauthorised disclosure of, or unauthorised access to, personal data. Cyberattacks regularly result in this when attackers gain unauthorised access.

In the case of a successful vCenter compromise, it must therefore be examined whether personal data in the appliance, on managed systems or in accessible storage could be affected. The controller must document the incident and the risk assessment. Under Art. 33 GDPR, where there is a risk to the rights and freedoms of natural persons, the competent supervisory authority must in principle be informed without undue delay and, where feasible, within 72 hours of becoming aware; a late report requires justification. Where no risk is likely to arise, the notification is not required – but the documentation obligation remains.

Where the risk is high, notification of the affected individuals without undue delay is additionally required under Art. 34 GDPR. Processors – such as your hosting provider – must inform the controller without undue delay. Art. 32 GDPR also requires technical and organisational measures appropriate to the risk, as well as, explicitly, a process for regularly testing and evaluating their effectiveness.

That security deficiencies and the quality of the response are relevant from a regulatory standpoint is shown by documented comparable cases: in 2018, following a hacker attack affecting around 330,000 user accounts, the LfDI Baden-Württemberg imposed a fine of 20,000 euros for storing passwords in plaintext. In 2020, following an attack, the UK's ICO imposed a fine of 20 million pounds on British Airways for inadequate data security. These decisions are not a fine forecast for a vCenter incident, but they do illustrate the potential scope. The specific assessment of an incident belongs in the hands of the controller, the data protection officer and, where appropriate, specialised legal advice. This is a general overview, not case-specific advice.

Risk assessment

For an unpatched vCenter instance reachable from the internet, the risk is acute and critical: the flaw allows code execution over the network without prior authentication, and real-world compromises including a persistence mechanism are documented. For an instance that is only internally reachable but unpatched, the risk remains high – an attacker can gain the necessary reach within the corporate network after some other initial access. For pure website operators without vCenter operation, there is no direct CVE risk, but there is a supply chain risk via the service provider.

Conclusion

CVE-2026-59310 is a case study in response speed: just five days after the patch, the first attacks began, and the campaign scaled within a few days to hundreds of affected IP addresses worldwide – with Germany among the five most affected countries. No workaround exists; the only effective remedy is the update to one of the fixed versions 9.1.0.0300, 9.0.2.0100, 8.0 U3k or 8.0 U2f.

If you run vCenter: treat the update as an emergency, remove any public reachability of the management interface, and check your systems for traces of reverse_ssh. Remember that a patch closes the vulnerability but does not eliminate remote access that has already been set up – only a forensic examination helps here. And if a service provider operates vCenter for you: ask them in writing today about patch status, reachability and compromise checks. That single email could make all the difference.