VMware ESX Logging Flaw Is Known to Be Exploited

What happened

VMware ESX has a security flaw that can leave certain administrator actions out of its logs. Think of a building's sign-in book: if some visits never get written down, reviewing the book cannot give you a complete account of who did what. Tracked as CVE-2026-41709, this issue allows a malicious administrator to carry out certain operations without those operations appearing in the logs.

The vendor's advisory identifies affected releases across VMware ESX, VMware Telco Cloud Platform, VMware Cloud Foundation, and VMware vSphere Foundation. NVD, the National Vulnerability Database, published the vulnerability on 2026-07-30 and assigns it a LOW severity rating. The issue concerns missing records of activity; the description does not identify which specific operations can go unlogged.

CVE-2026-41709 is known to be exploited. CISA added it to its Known Exploited Vulnerabilities (KEV) catalog on 2026-10-28, with a due date of 2026-11-11. That exploitation status matters when prioritizing updates, even though the numerical severity is low. KISA, Korea's Internet & Security Agency, also published an advisory on 2026-10-30.

Technical details

NVD classifies the weakness as CWE-778, Insufficient Logging. Logging is the process of recording system events so administrators and investigators can review activity afterward. Here, the security problem is that certain operations performed by a malicious administrator can escape that record. The root cause is insufficient logging coverage; the description does not establish a more specific implementation error.

The stated attack precondition is administrator access: the person exploiting the flaw is described as a malicious administrator. The description does not say that an unauthenticated visitor or an ordinary user can exploit it. It also does not describe a way to obtain administrator privileges. Keep those boundaries clear when assessing exposure: this advisory addresses what an administrator can do without leaving the expected log entries.

NVD assigns a CVSS 3.1 score of 2.7 and a severity of LOW. CVSS, the Common Vulnerability Scoring System, summarizes a vulnerability's technical severity. That score should be read alongside the stated administrator precondition and the logging impact. It does not mean exploitation has not happened: CISA KEV separately establishes that this vulnerability is known to be exploited.

The fixed release depends on the affected product and version branch. Some entries specify a product release, while others specify an ESXi build. Those labels are not interchangeable, so matching the installed product and branch to the vendor's advisory is essential before choosing an update.

Who is affected

Everyday users

For everyday users, this is primarily an issue for the administrators responsible for the VMware systems behind a service. The described exploitation requires a malicious administrator; it is not described as something an ordinary user triggers through routine use. If you do not manage the affected infrastructure, the practical response is to have its operator confirm whether the relevant updates have been applied.

The concern is accountability. Missing log entries can make it harder for the people responsible for a system to reconstruct certain administrator activity. The description does not establish that personal information was stolen or that services were disrupted, so those outcomes should not be assumed.

Developers

Developers whose applications run on affected VMware infrastructure should coordinate with the infrastructure team about the underlying product and update status. Changing application code does not address the logging weakness described in VMware ESX. The relevant work is identifying the affected infrastructure and applying the matching vendor fix.

When investigating unexpected behavior, keep the logging limitation in mind. An absent entry cannot establish that an operation affected by this flaw never occurred. The advisory does not identify those operations, so avoid assuming either that every log is unreliable or that an application log can fully account for administrator activity in the underlying infrastructure.

Server and IT admins

Server and IT administrators should treat this as an auditability issue with confirmed exploitation. Auditability means being able to review recorded activity and account for what happened. Because exploitation involves a malicious administrator, reviewing who has administrative access is relevant, but access restrictions do not repair the missing logging behavior.

Inventory the exact product and version branch before scheduling the update. VMware Cloud Foundation appears in several affected branches with different fixed targets, and VMware Telco Cloud Platform has its own entries. Use the vendor's advisory to resolve the correct update steps for your environment rather than selecting an update based only on a similar-looking version label.

What to do now

1. Identify whether your environment uses VMware Telco Cloud Platform, VMware Cloud Foundation, VMware ESX, or VMware vSphere Foundation. Record the installed version and match it to the corresponding affected branch in the vendor's advisory.
2. For VMware Telco Cloud Platform 5.0.x or 5.1.x, the advisory lists 8.0 U3j and later as the fixed version or action. Follow the update steps in the vendor's advisory to apply the appropriate update for that product.
3. For VMware Cloud Foundation 5.x, the listed fixed release is 5.2.4 and later. For VMware ESX 8.0, the listed fixed build is ESXi80U3j-25429389 and later. Follow the update steps in the vendor's advisory for the matching product.
4. For VMware Cloud Foundation 9.0.x.x and VMware vSphere Foundation 9.0.x.x, the listed fixed build is ESXi-9.0.2.0100-25595025 and later. Follow the update steps in the vendor's advisory.
5. For VMware Cloud Foundation 9.1.x.x and VMware vSphere Foundation 9.1.x.x, the listed fixed build is ESXi-9.1.0.0-25370933 and later. Follow the update steps in the vendor's advisory.
6. Prioritize the work using both the logging impact and the confirmed exploitation status. CISA KEV lists 2026-11-11 as the due date. Include that date in your remediation tracking without treating the LOW severity label as evidence that the issue can be ignored.

esxcli system version get

If you can't update yet

• Check the vendor advisory for applicable guidance on restricting administrative access while an update is pending. Limiting access addresses the stated administrator precondition, but it does not fix insufficient logging.

How to confirm the fix

• After completing the vendor's update steps, check the installed version again. For VMware ESX, use the listed ESXi shell command and compare the result with the fixed build for the relevant branch.
• Confirm that the installed release or build matches the fixed target for the exact product and affected branch. Do not use a fixed target from a different VMware product or branch as proof of remediation.
• Record the confirmed installed version and completion status for each affected system. The absence of suspicious log entries is not proof that this logging vulnerability has been fixed.

NVD scores and CISA KEV status

Listed in CISA's Known Exploited Vulnerabilities catalog: CVE-2026-41709 (added October 28, 2026). CISA adds a CVE only when it has evidence of exploitation in the real world.

Affected products and fixed versions 8 rows

The vendor's advisory is the authority on affected and fixed versions. If a cell says “See the vendor advisory”, check it there.

Frequently asked questions

References

• VMware advisory: https://support.broadcom.com/web/ecx/support-content-notification/-/external/content/SecurityAdvisories/0/38017
• NVD: CVE-2026-41709
• CISA Known Exploited Vulnerabilities catalog
• Also reported by KISA (Korea Internet & Security Agency) on October 30, 2026: KISA advisory (Korean)

How this page is made: versions and CVE IDs come from the vendor advisory table; CVSS scores and weakness types from NVD; exploitation status only from CISA KEV. The explainer is written with AI from those facts and published only after an automated check matches every version, CVE, score and command against the sources. Commands are limited to ones in official documentation. Always follow the vendor's advisory. Read in Korean.