A critical remote code execution vulnerability in VMware vCenter’s Syslog Server is under active exploitation right now. Tracked as CVE-2026-59310, the flaw carries a CVSS 3.1 score of 9.8 and is being used in a live campaign that drops an open source reverse SSH tool onto compromised hosts for persistence and remote access. If you run vCenter, this is not one to sit on.
What the vulnerability is
CVE-2026-59310 is a directory traversal vulnerability in the vCenter Syslog Server. What makes it nasty is that it lets an unauthenticated attacker achieve remote code execution. No credentials, no elaborate precondition, just network access to the affected service, and an attacker can run code on the appliance.
Directory traversal bugs in services that handle log forwarding are a classic target because those components are often reachable on the network and lightly defended. The Syslog Server is exactly that kind of component: it takes incoming log traffic, so it is exposed by design. That makes it a natural entry point.
How the active campaign works
According to BleepingComputer, the exploitation chain uses the open source reverse_ssh tool. After the initial compromise, attackers deploy this binary to establish a reverse tunnel back to their infrastructure. The point of a reverse SSH connection is that it inverts the traffic direction: instead of the attacker scanning in to the victim, the victim’s compromised host dials out to the attacker. That sidesteps inbound firewall rules and makes the connection look, at least on the surface, like outbound traffic.
Using reverse_ssh specifically matters. It is a legitimate, publicly available tool, which makes detection harder than a bespoke malware sample. It also gives attackers a reliable, interactive shell they can keep coming back to. The persistence angle is the part admins should worry about most, because a reverse tunnel that persists turns a one off RCE into a standing backdoor.
Patches and mitigation
VMware has released fixed versions to close the hole. Patches are available for vCenter 9.1, 9.0, and 8.0, which covers the supported release lines most organizations are running. There is no good reason to delay applying these, given the active exploitation and the severity score.
Beyond the patch, two practical steps matter. First, add detection rules that flag the reverse_ssh binary on endpoints, since that is the observed tool of choice in this campaign. Second, review outbound connections from vCenter hosts to unexpected destinations, because a reverse shell will announce itself through odd outbound traffic patterns. If you already have network monitoring in place, that is where this becomes visible.
Hunting for the backdoor
If you cannot rule out that your environment was already hit, the search has a few concrete angles. The reverse_ssh tool leaves a specific footprint that detection rules can target. Watch for the process name, unusual SSH connectivity, and the creation of the binary in locations where system services normally do not write files. Endpoint detection tools that flag outbound SSH from management hosts will cover a lot of the ground.
Log monitoring matters here too. A reverse tunnel means the compromised vCenter appliance is making outbound connections to an external host on a regular basis. That pattern differs from normal appliance behavior, which is mostly inbound management and occasional outbound update checks. A sudden, persistent outbound SSH session to an unknown IP is a strong signal worth escalating even if the process name is not on your blocklist.
For larger fleets, inventory the vCenter version across every cluster first. An unpatched node is a door you have not closed yet. Knowing the full exposure surface, not just the one appliance in the ticket, is the difference between fixing one host and fixing the whole estate.
Why this keeps happening
vCenter is a central piece of infrastructure in most VMware environments, which makes it an attractive target. A single compromise there can cascade into the virtual machines it manages. The pattern here, a critical unauthenticated RCE followed by fast in the wild exploitation, has become distressingly routine for enterprise management platforms.
The broader lesson is about logging and management-plane exposure. Components that legitimately accept network input, like syslog collectors, will keep being targeted because they are both reachable and powerful. Treating those services as high value attack surface, patching them first and monitoring them actively, has to be part of the baseline, not an afterthought.
The 9.8 CVSS score is worth pausing on. Very few vulnerabilities reach that tier, and the ones that do, like the Exchange and Citrix bugs that defined past incident response cycles, tend to show up in breach reports for years afterward. The fact that this one is unauthenticated and already has a working exploit in the wild puts it squarely in that company, which is why security teams should treat it with matching urgency rather than as another routine patch Tuesday item.
Bottom line for admins
The immediate action is unambiguous: patch vCenter to the fixed build for your version, and do it before the weekend if you can. The exploitable window on a 9.8 unauthenticated RCE with active malware in the wild is measured in days, not months. After patching, hunt for the reverse_ssh tool and any unusual outbound tunnels, because the campaign has already been running and it may have left a backdoor behind.