Four stories crossed my desk this week. A hypervisor bug rated 2.7 that attackers used as a zero-day. A critical flaw in the management layer of the private cloud, with a workaround and no patch yet. An SSH default that turned a "key-only" assumption into an open door on one Linux distribution. And a vendor announcement about tools that detect configuration drift and roll it back automatically. On the surface they have nothing in common. Honestly, they are the same story told four times: none of them is about a missing feature, all of them are about a decision nobody wrote down.
Let's start with the one that looks harmless. CVE-2026-41709 in VMware ESX is, in the words of the advisory text quoted by Tenable, an "insufficient logging vulnerability". A malicious administrator "could exploit this issue to perform certain operations without them being logged." The CVSS score is 2.7, low by every standard most patch processes use. According to CrowdStrike, as reported by The Hacker News, the China-nexus group Warp Panda exploited it as a zero-day in early 2026. Broadcom fixed it in July, CISA added it to the Known Exploited Vulnerabilities catalog on October 28, and US federal agencies have until November 11. The bug did not open a door. It turned off the camera, and the camera is exactly what you need afterwards to understand what happened.
Second, the management plane. VMSA-2026-0008 covers a remote code execution flaw in the Brotli decoder of Node.js as used in SDDC Manager. Broadcom rates it 9.8 for SDDC Manager 9.1.1 and 7.5 for 9.0.x, 9.1.0 and 5.2.x. As of today the advisory still lists every fixed version as "Patch pending", with workarounds in KB 460732 and KB 460734. Daily CyberSecurity sums up the interim advice as "limit network access to SDDC Manager to trusted admin hosts." Same library, different score, depending on where the code sits.
Third, OpenSSH shipped 10.6p2 as an emergency fix. On Alpine Linux, where sshd is built against musl and without PAM, an attacker with network access, an account name and a password between 257 and 1,024 bytes could get in under specific conditions. The Hacker News puts the key line plainly: "PasswordAuthentication is yes, which is the OpenSSH default." Many teams would have told you their systems were key-only. On those systems that was a belief, not a setting.
Fourth, on November 4 Broadcom announced that configuration management and compliance becomes a native part of VCF Operations, with "configuration drift detection and remediation" against benchmarks including PCI and the VCF Security Baseline, currently estimated for Broadcom's Q1FY27. Alongside it, VMware Compliance and Configuration Management, an Advanced Service built on VMware Salt, promises that "event-driven enforcement detects unauthorized file changes or exposed ports immediately and auto-remediates them." That is vendor language, and I will come back to it, because it is the most interesting of the four.
The Compliance and Configuration Management announcement has a sentence I like a lot: "Instead of writing scripts detailing how to configure a system, you simply define what the system should look like." Yes I know, that is the promise of every desired-state tool since configuration management was invented. And it is right. But the word "simply" carries the whole weight.
Because defining what a system should look like is not a technical task. It is a sequence of decisions. Should password authentication be off on every Linux host, including the appliance somebody deployed three years ago for a monitoring tool? Which networks may reach the management plane, and who signs off on the exception when a vendor support engineer needs access on a Friday night? Which admin operations on a host must be logged and, more importantly, who reads those logs? Bob Plankers wrote in the VCF blog last month that "Settings drift over time, new releases add controls and change defaults, and people make changes during troubleshooting that they never put back." Every one of those causes is human. A tool can find the difference between today and yesterday. It cannot tell you whether yesterday was right.
So an auto-remediation engine pointed at an undefined target does not give you security. It gives you consistency, and consistency of the wrong state is just a very efficient way of being wrong.
After more than 20 years of VMware architecture, my way of looking at this is four questions. Each of this week's stories failed at one of them, and each of them needs an owner, not a tool.
1. Defined: Is the desired state written down? Not in a wiki page from the original project, but as a baseline someone owns and versions. The OpenSSH case is the textbook example: the default was a decision, someone else made it, and nobody overrode it in writing.
2. Reachable: Who can reach the management plane? The SDDC Manager workaround is, in the end, a network decision. The Security Configuration Guide says management interfaces should be reachable "only from the networks administrators use, not from general user or workload networks and not from the internet." And Plankers adds the uncomfortable part: "Separate networks are a start, but VLANs by themselves don't provide isolation." If the honest answer to "who can reach it" is "half the office, because it was convenient once", that is the real vulnerability. The CVE just made it visible.
3. Visible: What would you actually see? The 2.7 logging bug is a reminder that visibility is part of the desired state too. Which admin actions on your hosts are logged, where do those logs go, can an administrator on the host tamper with them, and is anyone looking? If you prioritize purely by CVSS, you push exactly the fixes to the back of the queue that decide whether you can reconstruct an incident afterwards.
4. Enforced: Who owns the correction? Detection without a decision about what happens next is just a report. When drift is found, does it get rolled back automatically, raised as a change, or accepted as an exception with a name and a date on it? All three can be right. Not deciding is the only wrong answer.
Because the four questions get much easier to answer when the platform gives you one place to answer them. On a fragmented stack, the desired state of compute, storage, network and management lives in four tools and three teams, and drift between them is nobody's job. VCF does not make the decisions for you, but it gives you a common frame for them.
A few concrete things, all as Broadcom describes them. The VCF Security Configuration Guide gives you a prioritized baseline: in Plankers' words, "P0 is where there is not a secure default, and you should do this immediately," while P1 controls have an acceptable default that may not be as good as it could be. That is a ready-made list of decisions, sorted by urgency. The guidance on isolating infrastructure management describes how to keep the management plane reachable only from authorized networks or through a jump host. VCF Operations is where Broadcom is putting native configuration compliance and drift remediation for the infrastructure components, with the VCF Security Baseline as one of the benchmarks. And for the workloads on top, VMware Compliance and Configuration Management extends the same desired-state idea to VMs and containers, according to Broadcom's portfolio update, with CIS benchmarks or your own. One caveat Plankers makes himself: applying the hardening guide does not by itself make you compliant with PCI DSS or NIST, the mappings only save time.
How do we approach this at comdivision? We start where the tools stop: with the target state. Our approach is Architect, Educate, Operate, which in this context means three things. We design the target architecture including the baseline, so that "correct" is defined before the first host goes live, not reconstructed after an audit. We make sure the internal team understands why each setting is what it is, because a baseline nobody understands gets overridden during the next troubleshooting session. And the question we ask in every project is the one that matters here: what happens after go-live? [ERGÄNZEN: konkretes Vorgehen von comdivision bei Baseline/SCG-Umsetzung und Drift-Prüfung im Betrieb, z. B. Workshop oder Betriebsmodell, nur belegte Angaben] We are deliberately specialized in VCF and deliver clearly defined outcomes rather than open-ended hours, and a written, owned desired state is exactly the kind of outcome that survives the handover.
None of this week's stories needed a new product to be prevented. They needed someone to say, at some point, "this is how it should be, and I own that." Tools for drift detection and auto-remediation are genuinely useful, and I am glad they are becoming part of the platform. But a tool enforces a decision. It does not make one. If you have not decided what correct looks like, the best compliance engine in the world will faithfully enforce your indecision.
Define it. Own it. Then let the platform hold the line. #DecideOrGoHome
At comdivision we spend most of our time helping organizations design, run and harden VMware Cloud Foundation, from the target architecture to day-two operations. If you want to talk about how to turn "correct" into something written, owned and enforced in your environment, reach out to me.