Backstory
In March 2020, VMware merged a commit into open-vm-tools titled "Service Discovery plugin integration into open-vm-tools." It shipped in VMware Tools 11.1.0 and gave vRealize Operations 8.1.x a feature called credential-less service discovery. The feature removed a real security burden. Under the older credential-based mode, administrators stored privileged guest credentials in the monitoring platform so it could log into each virtual machine and run collector scripts. Credential-less mode moved collection inside the guest, where the VMware Tools daemon already ran as root. Broadcom's documentation states the mode is active by default and takes precedence over the credential-based path.
One of the new shell scripts, get-versions.sh, reported which version of each running service was installed. It listed the processes holding listening sockets, read each process command line with ps, matched that line against a regular expression, then ran the matched binary with a version flag such as -v and parsed the output.
The patterns described where system daemons normally live. One of them read /\S+/(httpd-prefork|httpd|httpd2-prefork)($|\s). The \S class matches any non-whitespace character, so the expression accepted /usr/sbin/httpd and /tmp/httpd with equal willingness. Comparable patterns covered mysqld, nginx, dataserver and vmware-dr. The script ran as root, so a process started from a writable directory under a matching name, holding a listening socket so that it would be enumerated, was executed as root.
Both the helper and those patterns appear in the original 2020 commit and survived the edits that followed. A commit dated July 31, 2020, "serviceDiscovery: Double quoting script variables that might contain whitespaces," rewrote the exact line that performs the execution, changing $COMMAND to "${COMMAND%%[[:space:]]*}". It corrected a whitespace-parsing problem on the line that runs the matched binary as root. Later commits extended the same file with Cassandra and vRealize Log Insight version checks. The code path stayed reachable for five and a half years.
VMware Tools has carried local privilege escalation bugs before: CVE-2022-31676 in August 2022, CVE-2023-34057 and the vmware-user-suid-wrapper file-descriptor hijack CVE-2023-34059 in October 2023, and the VMware Tools for Windows authorization bypass CVE-2025-22230 in March 2025. None of them sat in the discovery scripts.
NVISO's Maxime Thiebaut noted a forensic artifact anomaly on May 19, 2025, reproduced the issue in a lab on May 25, and opened disclosure with Broadcom on May 27. Broadcom extended the embargo on June 18 to align with release cycles and published VMSA-2025-0015 on September 29, 2025.
Technical analysis (revisited)
The original note described "improper permission handling on a core service or helper binary" and an attacker who manipulates or replaces "a specific file or configuration that is subsequently accessed and executed by a service running with higher privileges." The impact is right. The mechanism is more specific and involves the permissions on no VMware file at all. Nothing is replaced. The privileged process is handed a path it was never meant to accept, by a pattern that was too broad about what a service binary looks like.
NVISO published its analysis the same day the advisory landed. get_version() in get-versions.sh enumerates every process holding a listening socket and executes any binary whose command line matches one of the patterns. "While this functionality works as expected for system binaries (e.g. /usr/bin/httpd), the usage of the broad-matching \S character class (matching non-whitespace characters) in several of the regex patterns also matches non-system binaries (e.g. /tmp/httpd)." NVISO also confirmed that both collection modes are affected, credential-less through VMware Tools and legacy credential-based through Aria Operations itself, so switching modes was not a workaround.
The classification is contested across three parties. Broadcom, as CNA, assigned CWE-267, privilege defined with unsafe actions, and the CISA KEV record carries that label. NVISO's analysis calls it CWE-426, untrusted search path. Red Hat classifies it as CWE-280.
Red Hat also supplied the exposure scoping the vendor advisory omits, and the only documented workaround. The surface exists only where the service-discovery subpackage is installed: "Red Hat CoreOS (RHCOS) is not affected, as it only ships the standard open-vm-tools package, which by default, does not include the -sdmp subpackage." Red Hat's mitigations were to disable the servicediscovery plugin by configuration or to uninstall open-vm-tools-sdmp. Broadcom's advisory lists "Workarounds: None."
Broadcom's fix did not tighten the patterns. Commit 3ab0685c, dated September 30, added a version-check-enabled configuration key defaulting to FALSE, which skips get-versions.sh entirely. The commit message records the trade: "Disable (default) the execution of the SDMP get-versions.sh script. With the Linux SDMP get-versions.sh script disabled, version information of installed services will not be made available to VMware Aria." The key still defaults to FALSE in master.
Lifecycle timeline
- 2020-03-17: Service discovery plugin, including
get-versions.sh and the broad-matching patterns, merged into open-vm-tools (ships in VMware Tools 11.1.0)
- 2020-07-31: Hardening commit rewrites the execution line from
$COMMAND to "${COMMAND%%[[:space:]]*}"
- 2025-04-16: MITRE CVE record reserved (assigner VMware)
- 2025-05-19: Earliest dated in-the-wild artifact, per NVISO (NVISO separately places the start of exploitation at mid-October 2024 without publishing an exact day)
- 2025-05-25: Issue reproduced in a lab environment, per NVISO
- 2025-05-27: Disclosure to Broadcom initiated by Maxime Thiebaut, NVISO
- 2025-06-18: Broadcom extends the embargo to align with release cycles, per NVISO
- 2025-09-29: Broadcom advisory VMSA-2025-0015 published (initial revision, no exploitation acknowledgement)
- 2025-09-29: Patch released: VMware Tools 12.5.4 (fixes 11.x and 12.x; includes 12.4.9 for Windows 32-bit)
- 2025-09-29: Patch released: VMware Tools 13.0.5.0
- 2025-09-29: Patch released: VMware Aria Operations 8.18.5 (also the fix path for VMware Cloud Foundation 4.x/5.x and Telco Cloud Platform and Infrastructure, per the response matrix)
- 2025-09-29: Patch released: VMware Cloud Foundation Operations 9.0.1.0
- 2025-09-29: NVD entry published (CVSS 7.8, CWE-267)
- 2025-09-29: NVISO Labs publishes the technical write-up and the in-the-wild finding
- 2025-09-29: Ubuntu open-vm-tools update USN-7785-1 released (20.04 LTS, 22.04 LTS, 24.04 LTS, 25.04)
- 2025-09-30: Upstream open-vm-tools stable-12.5.4 and stable-13.0.5 published, with a backport patch provided to Linux distributors
- 2025-09-30: Fix commit 3ab0685c adds
version-check-enabled, defaulting to FALSE
- 2025-09-30: Debian 11 bullseye LTS ships 2:11.2.5-2+deb11u5
- 2025-09-30: Tenable Nessus plugin 266304 published (Ubuntu open-vm-tools, USN-7785-1)
- 2025-10-01: Qualys detections QID 733250 and 385437 announced
- 2025-10-02: Tenable Nessus plugin 266420 published (VMware Tools 11.x < 12.5.4 / 13.x < 13.0.5)
- 2025-10-30: Added to CISA KEV, remediation date 2025-11-20, ransomware campaign use "Unknown"
- 2025-10-30: Broadcom advisory revised to VMSA-2025-0015.1, adding the suspected in-the-wild exploitation note
- 2026-06-17: NVD record last modified
Real-world outcome
The note, dated September 29, recorded no known public proof-of-concept code and no reports of exploitation in the wild, and observed that the CVE was not listed on CISA KEV but was "a prime candidate for future inclusion." NVISO published on the same date, reporting zero-day exploitation beginning mid-October 2024, roughly eleven months before a patch existed, and attributing it to UNC5174, an actor Google assesses to be a contractor for China's Ministry of State Security. NVISO's earliest dated artifact is May 19, 2025. CISA added the CVE to the KEV catalog on October 30, 2025, with a November 20 remediation date and ransomware campaign use marked "Unknown."
The framing this case is usually given is one its primary source declines to make. NVISO wrote: "Throughout its incident response engagements, NVISO determined with confidence that UNC5174 triggered the local privilege escalation. We can however not assess whether this exploit was part of UNC5174's capabilities or whether the zero-day's usage was merely accidental due to its trivialness." Staging a payload at /tmp/httpd collides with the vulnerable pattern on its own, and Thiebaut has since suggested other malware families may have been triggering the escalation without knowing it. Mid-October 2024 is therefore a floor on observed triggering rather than a documented start of deliberate campaign use.
Broadcom's advisory carried no exploitation acknowledgement when it was published. SecurityWeek noted that "the company's public advisories typically warn customers if zero-day exploitation has been detected." Qualys was publishing the CVE as actively exploited by October 1. Revision .1, on October 30, the same day as the KEV listing, added one sentence: "Broadcom has information to suggest that suspected exploitation of CVE-2025-41244 has occurred in the wild." It named no actor, gave no date range, listed no indicators, and did not change the 7.8 score.
Lessons
A pattern written to describe where a program usually lives is not an authorization decision, and this code path used it as one. The expressions in get-versions.sh were accurate about system daemons and silent about who was permitted to be one. What set the impact was not the quality of the match but the privilege of the process doing the matching.
The case also shows that a feature can be a security improvement and an exposure at the same time. Credential-less discovery exists so that privileged guest credentials do not have to be stored in a monitoring platform, which removes a real risk. It works by having a root daemon inside the guest enumerate and probe local processes. The stored credential is gone and a root execution path is new.
A hardening commit landed on the vulnerable line in July 2020 and changed how the command string was quoted. Quoting was the defect it was looking for. Whether the matched path should be trusted at all was a different question, and editing that line did not surface it.
Broadcom's remediation was to stop calling the script by default rather than to narrow the patterns, which puts the feature's value and its blast radius on one ledger: service version reporting to Aria Operations is off unless an operator turns it back on.
The exploitation record here rests on one incident-response vendor's telemetry, and that vendor states it cannot determine whether the trigger was deliberate. A bug simple enough to fire by accident produces evidence that looks the same either way.
References