Attackers exploit patched VMware vCenter flaw to plant persistent reverse SSH access
Five days between disclosure and mass exploitation shows why patch windows for management planes are measured in hours, not weeks.
A critical vulnerability in Broadcom's VMware vCenter Server is being actively exploited to establish long-term access to virtualisation management hosts, according to a report published on 12 August by The Hacker News. The flaw, tracked as CVE-2026-59310 with a CVSS score of 9.8, is a directory traversal weakness that lets an attacker with network access execute arbitrary code on the appliance. Broadcom released patches in late July 2026.
German security firm QUIRSO identified the campaign after an incident response engagement. Its analysis describes path traversal activity consistent with the flaw, followed by the installation of a malicious cron job so that the attacker's code survives reboots. The intruders then deployed reverse_ssh, an open-source tool that opens an SSH connection outward to infrastructure the attacker controls, giving them a persistent remote shell.
The scale is significant. QUIRSO counted 361 unique victim IP addresses across 47 countries, with the largest concentrations in Germany, the United States, Turkey, Iran and France. Compromised systems began contacting attacker domains on 3 August, only five days after Broadcom's public disclosure. The report attributes the activity to a suspected advanced persistent threat actor and notes a likely connection to Chinese groups that have historically targeted VMware appliances.
vCenter is the control plane for VMware environments, so a compromised instance can expose every virtual machine it manages. The immediate advice is to apply the July patches, check for unexpected cron entries and outbound SSH sessions, and treat any internet-reachable vCenter as a likely target.
Why it matters
The gap between disclosure and exploitation has shrunk from weeks to days. Attackers favour targets that sit above workloads, because one foothold in a hypervisor manager beats dozens in individual servers. Using an off-the-shelf reverse SSH tool and a cron job shows how little novelty is needed when the entry point is this powerful. Vendors will face growing pressure to ship fixes with detection guidance on the same day.
The gap between disclosure and exploitation has shrunk from weeks to days.
Broadcom discloses CVE-2026-59310
Directory traversal in vCenter Server, CVSS 9.8, patched late July 2026
Path traversal request
Crafted requests escape the intended directory and lead to code execution
Malicious cron job installed
Scheduled entry keeps the attacker's code running across reboots
reverse_ssh deployed
Host dials out over SSH to attacker infrastructure for a persistent shell
Beaconing from 3 August
361 victim IPs in 47 countries observed contacting attacker domains
What you can learn from this
- Directory traversal. Web applications often build file paths by joining a fixed base directory with a user-supplied name. If the input is not normalised, sequences such as
../let the request escape the intended folder and read or write files elsewhere on the system. When the writable location happens to be somewhere the server later executes, such as a script directory or a scheduled-task folder, traversal turns into code execution. The fix is to canonicalise the path and verify it still starts with the base directory before touching the filesystem. - The management plane as the crown jewel. Systems like vCenter, cloud consoles and orchestration APIs exist to control other systems, so they hold credentials and privileges far beyond any single workload. An attacker who owns the manager can clone disks, snapshot memory, add backdoor accounts or quietly disable logging on everything beneath it. This is why security frameworks insist management interfaces sit on isolated networks reachable only through a bastion or VPN, and why zero-trust designs demand per-session authentication even from inside the network. Exposure to the open internet converts every future bug into an emergency.
- Persistence through the scheduler. cron on Linux and the Task Scheduler on Windows run commands at set times with the privileges of the account that created them. Adding an entry is a one-line change that survives reboots, is easy to miss in a crowded crontab, and looks like routine maintenance to a casual reviewer. Attackers favour it because it needs no exploit of its own and no unusual binary on disk. Defenders counter with file-integrity monitoring on scheduler directories and alerts on new entries.
- Reverse shells and reverse SSH. Inbound connections to a server are usually blocked by firewalls, but outbound connections are often allowed. A reverse shell flips the direction: the victim machine dials out to the attacker, who then sends commands back through the established session. Tools such as reverse_ssh wrap this in standard SSH so the traffic is encrypted and blends with legitimate administration. Egress filtering, which restricts where servers may connect to, is the structural defence.
- The shrinking exploitation window. Once a vendor publishes a patch, attackers can diff the old and new binaries to locate the change and reconstruct the bug. Automated scanning of the internet for vulnerable versions then takes hours. Five days from disclosure to mass exploitation is now typical for widely deployed appliances, which is why a policy of patching within 30 days is no longer adequate for anything internet-facing. Risk-based patching prioritises exposure and privilege over CVSS alone, and emergency change procedures exist precisely so a fix can go in the same day without waiting for the monthly cycle.
We teach this
How to use this in practice
- Map what management interfaces you expose. From a machine outside your network, run
nmap -p 443,5480,22 <your public range>against addresses you own, or use your cloud provider's inventory to list hosts with management ports open. For each result, write down what it manages, who should be able to reach it, and whether a VPN or bastion could sit in front of it. Done means a one-page table where every internet-reachable admin interface has a justification or a ticket to close it. - Audit scheduled tasks on one Linux host. Run
sudo ls -la /etc/cron.d /etc/cron.daily /var/spool/cron/crontabsandsudo crontab -l -u root, then read every entry. For anything you cannot explain, trace the script it calls, check its creation date withstat, and confirm which account owns it. Save the output to a dated file. Done means a saved baseline of expected entries that you can diff against next month with a single command. - Restrict outbound connections from a server. Pick one non-critical server and write an egress rule that only permits outbound traffic to the update mirrors and internal services it genuinely needs, using
ufw,iptablesor a cloud security group. Then try to open an outbound SSH session from it to a host you control, repeat the test on port 443 to confirm the rule is not SSH-specific, and check that a package update still succeeds. Done means the test connection fails, the update works, and the rule is documented next to the server's build notes. - Draw the attack chain. Sketch five boxes: disclosure, traversal request, code execution, cron persistence, reverse SSH beacon. Next to each box, write the single log source or control that would have revealed or blocked that step, such as web server access logs, file-integrity alerts on cron directories, or egress denies. Then circle the earliest point where you would realistically have caught it today. Done means every box has at least one named detection you could actually configure this week.
Sources
Our reporting is an original summary; full coverage is at the links above.
Don't just read about it — build it.
Square 1 teaches the skills behind the headlines, with every line of your work graded by AI. Find your starting point in 3 minutes.
Get your free skill report