All articles

NewsOctober 28, 20264 min read

VMware ESX: logging flaw exploited, CVE-2026-41709 in KEV

CVE-2026-41709: in VMware ESX a malicious administrator can perform operations without leaving a trace in the logs. CISA lists it as already exploited.

Confidential security document with an approval stamp and a wooden rubber stamp lying on top

On 28 October 2026 CISA added CVE-2026-41709 to its Known Exploited Vulnerabilities (KEV) catalogue. The catalogue calls it “Broadcom VMware ESX Insufficient Logging Vulnerability”: an insufficient logging vulnerability in Broadcom’s VMware ESX hypervisor which, by being added to KEV, is confirmed as exploited in real attacks.

For US federal agencies the remediation deadline is 11 November 2026. The CVE record in the NVD database was published on 30 July 2026 and updated on 28 October; NVD currently lists it as still under analysis.

This article is based on a single source, the KEV catalogue entry with the description published in the NVD database: the information that follows is what is reported there.

What happened

According to the description published in the NVD database, VMware ESX contains an insufficient logging vulnerability: a malicious administrator could exploit it to perform certain operations without them being logged.

The description does not say which operations escape the logs, or under which conditions. This is therefore not a flaw that opens access to the host: exploiting it already requires administrator privileges. Its effect is different: what the administrator does may leave no trace in the logs that monitoring and investigations rely on.

Technical details

  • CVE: CVE-2026-41709.
  • Product: Broadcom VMware ESX, as named in the source.
  • Weakness: CWE-778 (Insufficient Logging).
  • CVSS 3.1 score: 2.7 (low), calculated by VMware: network attack vector, low complexity, high privileges, no user interaction, unchanged scope, no impact on confidentiality and availability, low impact on integrity.
  • Affected and fixed versions: not reported by the source; they are in the Broadcom security advisory referenced by the NVD record.
  • Exploitation: confirmed by CISA through the KEV listing. Use in ransomware campaigns is, according to CISA, currently unknown.
  • Attack chain and indicators: the source does not describe how the vulnerability was exploited and gives no MITRE ATT&CK techniques or indicators of compromise.

The low score reflects the fact that the vulnerability, on its own, grants no access: an administrative account is required. The KEV listing, however, says it has been used in real attacks. In the required action, CISA also refers to its own forensics triage requirements.

Impact for European and Italian companies

An ESX host usually runs many virtual machines: application servers, databases, sometimes domain controllers. Whoever holds its administrator privileges acts on everything running on it. A vulnerability that allows doing so, at least in part, without leaving a trace in the logs mainly affects the ability to reconstruct events after an incident.

For entities in scope of NIS2, timely vulnerability handling and event logging are part of the required measures, and a compromise must be assessed for notification to the national CSIRT, which in Italy is CSIRT Italia at ACN. The same applies to healthcare organisations running their systems on virtualised infrastructure.

What to do now

  1. Inventory: identify all VMware ESX hosts, including those managed by providers or in lab environments, and compare their versions with the Broadcom advisory.
  2. Update: apply the fixes or mitigations provided by Broadcom. CISA asks organisations to apply the vendor’s mitigations or, if none are available, to discontinue use of the product.
  3. Reduce exposure: CISA asks organisations to assess how exposed each system is to the internet. Host management interfaces should be reachable only from the management network.
  4. Review administrative accounts: exploiting the vulnerability requires high privileges. Check who has administrator access to the hosts, remove accounts no longer in use and replace shared credentials.
  5. Don’t rely on host logs alone: the vulnerability is precisely about what does not get logged. Forward host logs to an external system and compare them with other sources, such as network, firewall and management console logs.
  6. Look for signs of compromise: if a host administrator account may have been used by someone else, follow forensic triage guidance and check configurations and virtual machines even where the logs show no activity.

How ARXDOME helps

ARX Sentry collects logs and events from servers running the agent and logs from firewalls, including account changes and privileged access: sources independent of the host against which to compare what does, or does not, appear in its logs. ARX Retain stores logs on European storage with object lock, which prevents them from being changed or deleted. ARX Expose shows which services your company exposes to the internet and which products are recognised on them, while ARX Shield lists the open vulnerabilities on monitored machines and highlights those already exploited. With ARX Horizon you can look up vulnerability details from the portal.

Last updated:

Any questions?

Let’s talk about your company’s needs, with no obligation.

Contact us

Related articles