The vCenter advisory said there was no known exploitation. It held for five days

On 30 July we wrote here about VMSA-2026-0006 and, among the advisory's details, we quoted a sentence from Broadcom: it had no information suggesting exploitation in the wild for any of those five flaws. Rapid7, analysing the advisory that same day, put it even more broadly: no known exploitation and no scanning for either of the two 9.8s in vCenter. Both statements were true on 29 July. Five days later, on 3 August, the first compromised vCenters started connecting to attacker infrastructure.

This is not a correction of that post: the fact was right, and it still is with its date attached. What has changed is the weight we give that kind of sentence when someone uses it — and it gets used a lot — to argue that the maintenance window can wait until September. We run VMware and Proxmox in production and we sell licences for neither, so there is nothing to push here. There is a calendar, some numbers with their caveats, and a question almost nobody can answer in under half an hour.

The calendar, day by day

On 12 August, German firm QUIRSO published what it found in the course of an incident response engagement: an active campaign against internet-accessible vCenter systems, tentatively attributed to an APT actor, exploiting CVE-2026-59310 — the directory traversal in the vCenter Syslog server, CVSS 9.8, no credentials required — and leaving reverse_ssh behind through a cron job.

The shape of that curve matters more than the total. There is one peak day and a week in which nearly everything has already happened, with no months-long trickle beforehand. Anyone planning patches by quarter is competing against a campaign that put 95 % of its known victims on the board within seven days of the advisory — and was still adding to the list when the report went out: eighteen more addresses between 6 and 12 August.

What those 361 do not say

The researchers themselves put three limits on their own figure, and it strikes us as the most honest part of the report:

• 361 IPs are not 361 companies. They say it plainly: the number of victim organisations cannot be inferred from those addresses, because an IP does not necessarily map to a single company or physical system. There may be several behind one, and one company behind several.
• Finding reverse_ssh proves nothing on its own. It is a legitimate open-source tool — SSH-based reverse shell, port forwarding, file transfer — and the authors themselves warn that its presence should not, by itself, be treated as proof of malicious activity. It has to be correlated with other indicators.
• The indicators are not published yet. QUIRSO says attacker-specific indicators and further detection content will come later, coordinated with law enforcement so as not to interfere with an ongoing investigation. For now there is a YARA rule to hunt for reverse_ssh and little else. If you were expecting a list of IPs to drop into the firewall this afternoon, there isn't one.

A number that comes with its own limits is worth far more than a round number without them. We say so because over the next few days that 361 will turn up in sales decks as "361 companies hacked", and that is not what the report says.

The sentence in the advisory you have to learn to read

"At the time of publication there is no known evidence of exploitation or scanning." That broader wording is Rapid7's; Broadcom's advisory says half of it — that it has no information suggesting exploitation in the wild — and that is the one we reproduced. Both were true on 29 July. What fails is how we read them: they get read as a forecast when they are a snapshot of the writer's telemetry, on the day of writing. Their value expires almost the instant they are printed, because the advisory itself is what sends everyone to look at the same place.

The researchers say it with the caveat in front: while the attacker might have had prior knowledge of the vulnerability, the strong correlation between the disclosure date and the start of exploitation suggests the disclosure itself was the starting point of the campaign. It is the same old asymmetry, now with dates on the table. The advisory notifies both sides at once, and only one of them has to request a maintenance window, coordinate with the billing application vendor and wait until next Tuesday.

Nobody should read this as an argument against publishing advisories: without that document you could not have patched anything. What does not hold up is using "no known evidence" as a reason to delay. Our rule, for a long time now, is to treat that sentence as information about the past and to calculate urgency from the only thing that is actually a property of the flaw: whether authentication is needed, whether interaction is needed, and from where the service can be reached. Neither of this advisory's two vCenter 9.8s asks for credentials; the rest is arithmetic.

The phrase doing all the work: "internet-accessible"

The 9.8 CVSS assumes the attacker has network access to the service, and who has that access is your decision. That is why the campaign is not aimed at every vCenter in the world but at the ones that answer from the internet: that is the filter separating those 361 addresses from the rest of the global estate, and it is the only part of the equation still in your hands once the advisory is out.

The uncomfortable question, then, is not "have we patched it?". It is "who can open a TCP connection to our vCenter?". In most of the places we walk into, that answer is not written down anywhere: it gets reconstructed by looking at firewall rules left by someone who no longer works there, a temporary rule from a 2023 project, and a VPN that in practice grants access to the entire management VLAN. Reconstructing it takes an afternoon. Having it written down, and reviewed, is literally what Zero Trust is for: the management plane gets no special privileges for being internal, and whoever does not need to reach it does not reach it.

And the honest counterweight, also written into the analyses of this advisory: restricting management interfaces to an internal or dedicated network reduces internet exposure but does not mitigate the risk from an attacker who already has access to your network. Taking vCenter off the internet removes you from this particular campaign's census; it does not remove you from the problem. Put another way: exposure explains who got in during August, not who could get in next month from an already-compromised laptop. That distinction is what made us write about another vendor's management console, and here it comes back with dates attached.

What to check this afternoon if you run vSphere

• The exact version, not the one you remember. With PowerCLI, after Connect-VIServer, the $global:DefaultVIServer.Version and .Build variables. The fixed versions reported in the advisory analyses are 9.1.0.0300 for the 9.1 branch, 9.0.2.0100 for 9.0 and 8.0 U3k for 8.0; revision VMSA-2026-0006.1, dated 3 August, added the 8.0 U2f express patches for vCenter and ESX for anyone on Update 2, so there is no need to jump an update to close this. There is no workaround: you either patch or you stay exposed.
• Exposure, measured from outside. On the LAN everything is always reachable, so the test has to come from an internet IP: does vCenter answer? Does the syslog service — precisely the component with the flaw — answer? If the answer to either is "I don't know", you have found where to start.
• If you were exposed and unpatched between 29 July and today, "it's patched now" does not close the matter. You have to look for cron jobs nobody remembers creating on the appliance and, above all, outbound connections: a vCenter has no business initiating SSH sessions to the internet. We wrote this about another vendor and the argument has not aged: applying the patch does not evict whoever was already inside.
• The logs from that period, with reservations. In our 30 July post we said the lowest-scoring flaw in the batch — insufficient logging on ESX — was the one that would decide whether a later report says "this is what they did" or "this is what we think they did". Two weeks on, there are people writing exactly that report. If it falls to you, the full advisory breakdown is here.
• The date and time of everything you do. Which version you had, when the patch was applied, who applied it, and what was left pending. In an incident that timeline is worth more than any tool, and it is the first thing you will be asked for.

The distance that actually matters

Out of this whole episode, the number that worries us is not 361 but the distance between "a critical advisory is published for a product we run" and "someone with authority is looking at it". This time that distance had to be under five days, in August, with half the staff on holiday. In most organisations it does not depend on the technical team, who usually hear about it on day one, but on whether there is a shift with the authority to approve an urgent change without waiting for the September committee. It is the least glamorous part of 24×7 support and the one that decides whether you show up in a count like this one.

Which does not mean everyone should declare an emergency today. If your vCenter has never answered from the internet and you patched in the first week, you are not in this campaign's population, and an emergency change now will only cost you attention and mistakes. We say this even though it sounds odd coming from people who sell security services: not every 9.8 advisory is your fire. Nor is it an argument for switching hypervisor — Proxmox publishes its own advisories, with its own reboots and windows — because what moves from one platform to another is the work, not the clock.

Sources (verified): the active campaign against internet-accessible vCenter, the 361 victim IP addresses across 47 countries, first contact with attacker infrastructure on 3 August (five days after the advisory), the peak of 151 new addresses on 4 August, 343 of 361 reached by 5 August, the five most affected countries (185 of 361), the use of reverse_ssh, the warning that an IP does not equal an organisation, the warning that the presence of reverse_ssh is not by itself proof of malicious activity, and the deferral of indicators pending coordination with law enforcement — QUIRSO GmbH report (12 August 2026) and The Hacker News coverage, which is also the source for the cron job that establishes persistence. The description of CVE-2026-59310 (directory traversal in the vCenter Syslog server, CVSS 9.8, unauthenticated), the VMSA-2026-0006 advisory date (29 July 2026), the sentence "at the time of publication there is no known evidence of exploitation or scanning", the fixed versions, and the observation that restricting management interfaces to internal networks reduces internet exposure but does not mitigate an attacker already inside the network: Rapid7 analysis. Reading the advisory sentence as a snapshot rather than a forecast, the question of who can open a connection to your vCenter, the criteria for when NOT to declare an emergency, and the rule of timestamping everything applied are ours. Image: sports stopwatch (rawpixel, CC0).