ESXi: the 2.7 we ranked fifth was a zero-day

Ninety days exactly. On 30 July we published a triage of the VMware bulletin and left CVE-2026-41709 fifth out of five, because that is what it scores: 2.7 out of 10. We gave it a section of its own and called it "the flaw nobody is going to look at"; what we did not do was move it up the list. On 28 October CISA added it to its Known Exploited Vulnerabilities catalog. An adversary was using it as a zero-day.

This post is not about saying "we told you so". It is the opposite: about the two things we wrote back then that October's data forces us to correct. If you only want the actionable part, skip to the checklist at the end; there are six checks and none of them is "apply the patch".

What happened in ninety days

Four dates, and where each one comes from:

Why a low number does not measure your ability to reconstruct what happened is already in what we wrote on 30 July and we are not going to repeat it here. What that post could not know is what comes next.

Correction 1: the doubtful window does not start on the advisory date

In July we gave a short rule: patch, mark the log period before the patch as unreliable, and do not accept a "nothing looks odd" from that period as a clean review. The rule still holds — we said "before the patch", with no start date — but we did not say out loud what now needs saying: that window does not start when the vendor publishes either. We left it open; plenty of people close it on the advisory date.

A zero-day is, by definition, exploitation that predates the advisory. CrowdStrike places the use of this CVE "as late as early 2026" inside intrusions from a report whose observation period starts on 1 September 2025. Let us be precise about what that allows us to claim and what it does not: the report publishes no start date for exploitation of this particular CVE. What is clear is that July's bulletin bounds nothing going backwards. If you write a report saying "we reviewed the period since the advisory was published", you are bounding by the wrong date.

It already happened to us with another CVE from that same bulletin: "no known exploitation" lasted five days after publication. The difference is scale. There the gap was counted in days; here, at best, in months.

Correction 2: shipping logs off the box does not fix this

Eleven days ago we wrote that logs have to leave the box, because the log living inside the compromised box is the least trustworthy evidence. We stand by it, and it is also of no use here.

Remote syslog, SIEM, immutable storage, event signing: all of that protects the transport and custody of an event that first has to exist. CISA's description is unambiguous about where this happens: "perform certain operations without being logged". It is not a deletion. It is a non-write.

And that distinction changes the whole investigation. A deletion leaves traces: gaps of minutes, a sequence number that jumps, a daily volume that drops. All of that is detectable. An operation that was never written leaves a record that is coherent, continuous and apparently complete. There is no anomaly to look for, because nothing is missing: it was never there. It is the difference between a torn-out page and a blank one.

And here we have to slow down: the text says "certain operations", not "all". Nobody has published which ones. That bounds the damage and, at the same time, makes it impossible to say which part of your log is sound.

Why it took ninety days (and why it will happen again)

CISA's catalog is literally called "known exploited vulnerabilities". Knowing requires evidence. And the evidence for this flaw is exactly what the flaw prevents from being generated. It was never going to come out of anyone's SIEM: it came out of an incident-response vendor's report, written by people reading memory and disk on real victims, not dashboards.

Hence the thesis: if your patching policy follows what is in the catalog, this family of flaws will always reach you last — not through negligence, but by construction. Logging flaws take the longest to be proven exploited precisely because their effect is that nothing gets proven.

One detail illustrates it well. CISA added two CVEs on that same 28 October. The ESX one got a deadline of 11 November: fourteen days. The other, a Linux kernel flaw chainable to plant webshells and run as root, got 31 October: three days. The deadlines come from the table in directive BOD 26-04, dated 10 June 2026, built on the same SSVC factors CISA records in every entry. And the two are marked identically in almost everything — exploitation "active", automatable "no" — so the only thing separating them is technical impact: "partial" for the ESX one, "total" for the kernel one. That single box is eleven days of difference.

And let it be said: the 2.7 is not wrong. CVSS measures what it measures, and to use this flaw you must already be an administrator (PR:H). What fails is having a single work queue and sorting it by that number.

What almost nobody needs to do now is patch

And now the odd part. The fix for this CVE shipped in the same July bulletin as the two 9.8s and the VM escape. In fact, CISA's entry points to that same Broadcom portal reference. Whoever applied that advisory already fixed it, without knowing, three months ago. With one caveat that is not minor: the advisory was revised twice — the express patches for ESX and vCenter 8.0 U2f landed on 3 August and the guidance for 7.0 on the 19th — so "July" is not the same date for all your hosts. Hence the first check.

So the KEV listing does not create a patching task for you. It creates an evidence task, which is the one nobody has in their process. Our patch workflow is full of "applied / pending" and empty of "what stopped being true when this came to light". That gets fixed in the committee, not in the maintenance window.

Conflict of interest up front: the monthly committee that follows is a service we bill for. It is, literally, what we do in the Programa RID: a monthly committee with an owner and a date, where open risks are reviewed and so are the closed ones whose meaning has changed. The detection and response part is covered by managed cybersecurity. We will say it plainly: this is not bought with a tool, it is sustained by a meeting someone calls every month.

Six checks, none of them is "patch"

Before somebody tells this badly in a meeting

Because the alarmist version of this is going around too, and it does not hold:

• Using it means already being an administrator (PR:H), so it is not a way in. If nobody reached that level on your hosts, this did not happen to you. Mind how you check that: the ESX log itself does not prove it, since that is precisely the one that does not hold here. The second witness does.
• It does not switch your logging off. "Certain operations", says the text. The rest keeps being written.
• It is not a mass campaign. CISA marks it as not automatable and with no known ransomware use. What is documented for this CVE is targeted espionage against US entities, with the legal sector among the targets. The adversary, however, also operates against Japan, Taiwan and South Korea: absence from one report is not absence from the world.
• Patching is not urgent if you already applied the July bulletin. If you did not, your problem is not this CVE: it is the other four in the same batch.

The file somebody signed off in July

A bulletin is closed the day the patch lands and, from then on, nobody goes back. Ninety days later somebody publishes the missing piece and the file we considered closed says something else. If you run vCenter and ESX in production and that file was signed off by someone in July, drop us a line and we will go through it together.

Sources (verified on 30 October 2026): the 2.7 score, the vector CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:N/I:L/A:N, the CWE-778 classification, the publication date (30-07-2026) and CISA's SSVC record of 28-10-2026 (active / no / partial) come from the NVD entry for CVE-2026-41709, queried through the API. The official title, the description ("perform certain operations without being logged"), the 28-10-2026 listing, the 11-11-2026 deadline and the "Unknown" ransomware flag come from CISA's KEV catalog, a file we downloaded and read ourselves. The quote about zero-day exploitation, the WARP PANDA adversary, the path (edge devices into vCenter) and the 01-09-2025 to 31-08-2026 observation period are from CrowdStrike's 2026 legal-sector report (28-10-2026). The three-day deadline for the second CVE added the same day (CVE-2026-46300, Linux kernel) and its chaining to plant webshells and run as root are in its own catalog entry. The deadline table and its construction on SSVC factors are from directive BOD 26-04 (10-06-2026), whose Table 1 is published as an image: that is why we do not quote the box-to-deadline mapping verbatim, although both deadlines and all four SSVC factors are published. The revision dates of the July advisory (version .1 of 03-08-2026 and .2 of 19-08-2026) come from the change log of Broadcom's own advisory. The ninety days, the torn-page versus blank-page distinction, the thesis on why this family of flaws always reaches the catalog last, the two corrections of our own posts and the six checks are our own arithmetic and reading.