Labs

Scenic
RDAP/WHOIS matrix
Pouch
Safer secrets
Churn News
Perpetual satire
Choice Reviews
Rigorous testing

Services

Development
Web applications, mobile applications, Backend & distributed systems, API design & integration, database design & scaling
AI
Model training & fine-tuning, LLM application design, Agentic tooling & knowledge integration
Security
Penetration testing, Red team & adversary emulation, Attack surface discovery & exposure management
Infrastructure
Cloud architecture, Containerization & platform engineering, CI/CD pipelines & release engineering, Observability & SRE

Analysis

When Service Discovery Trusts Too Much

Bob Sacamano, Practice Lead
Sep 30, 2025

The CVE-2025-41244 entry documents a local privilege escalation in VMware’s service discovery pipeline that allows a non‑administrative user on a guest virtual machine to become root when specific management features are enabled. The MITRE CVE record corroborates the assignment and scope while designating Broadcom (VMware) as the CNA of record. The Broadcom advisory VMSA‑2025‑0015 ties the flaw to both VMware Tools and VMware Aria Operations, clarifying that exploitation requires Service Discovery Management Pack (SDMP) functionality to be active under Aria Operations management.

The NVISO analysis provides the clearest technical anatomy and shows two operational modes that hit the same fault line. In the legacy “credential‑based” mode, Aria Operations connects into a guest and runs metrics‑collection scripts with elevated credentials; in the modern “credential‑less” mode, the collection logic lives inside VMware Tools under a privileged service. NVISO demonstrates that in both cases the service discovery logic will match and execute attacker‑controlled binaries if their paths satisfy permissive regular expressions used by the version‑discovery code, so a low‑privilege user who can place and run a plausible‑looking process can be promoted to a root‑context command execution by the discovery routine’s follow‑on invocation.

Upstream evidence shows the precise fault location. The open‑source implementation of VMware Tools’ SDMP logic includes the get‑versions.sh script, whose generic get_version function searches command lines for broad regular‑expression patterns corresponding to “known” services and then executes the matched binary with a version flag. NVISO’s write‑up explains that several patterns use the \S character class, so they match non‑whitespace characters from any path rather than restricting execution to system directories, which means a path like /tmp/httpd can be selected and run with root privileges during discovery. The same logic explains why the exploit requires a listener: service discovery enumerates processes with open sockets, then tests their command lines against those regexes; if a planted binary is already running and listening, it will be captured and then invoked by the discovery code with the expected “‑v” or “‑‑version” argument in a privileged context.

The exploitability of this code path is reinforced by upstream maintenance notes. The VMware Tools maintainers published a dedicated CVE‑2025‑41244.patch bundle and stated that official fixes shipped in open‑vm‑tools 13.0.5 and 12.5.4 on 2025‑09‑29, together with backportable patches for earlier supported series. The patch set disables the vulnerable behavior in the SDMP path and provides cleanly applying diffs for common distributions, indicating that the remediation was engineered for rapid vendor integration and backports.

The incident has clear indicators in forensic and runtime telemetry. NVISO details that a common in‑the‑wild path used by intruders is /tmp/httpd and that following exploitation one can observe a child process tree where a privileged vmtoolsd or discovery script invokes a non‑system binary with a “‑v” argument, sometimes leaving temporary artifacts under /tmp/VMware‑SDMP‑Scripts‑{UUID}. These claims are consistent with the upstream code’s version‑discovery design and with the patch disabling the script path, and they are significant because they provide operators with concrete triage cues before and after patching. NVISO further notes that the privilege escalation can be reached by either the Aria Operations script runner or the credential‑less collector, which makes the detection patterns symmetric across both operational modes.

Severity and classification align across the canonical records but differ in emphasis. The NVD entry reports a CVSS v3.1 base score of 7.8 with the vector AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H, which captures that a local user with low privileges and no user interaction can fully compromise confidentiality, integrity, and availability through this failure mode. The CNA’s description in the NVD record also specifies the precondition that VMware Tools must be installed on the guest and managed by Aria Operations with SDMP enabled, which materially narrows exposure to managed fleets. On the taxonomy side, NVD maps the root cause to CWE‑267, Privilege Defined With Unsafe Actions, highlighting the conceptual error of letting privileged logic perform unsafe operations on untrusted inputs, while NVISO frames the concrete mechanism as an untrusted‑search‑path issue akin to CWE‑426, because the regex patterns allow execution from user‑writable locations; both characterizations describe complementary aspects of the same failure: a privileged component executing code from paths it should not trust.

The discovery and disclosure timeline is unusually transparent. NVISO states that its incident response team noticed anomalous remnants attributable to an unknown elevation on 2025‑05‑19, attributed the event to a zero‑day on 2025‑05‑21, reproduced it by 2025‑05‑25, and initiated coordinated disclosure on 2025‑05‑27; Broadcom extended the embargo to align with product release cycles on 2025‑06‑18 and published patches on 2025‑09‑29. NVISO adds that in‑the‑wild exploitation started in mid‑October 2024, well before disclosure, and attributes operational use to the China‑linked actor UNC5174, an attribution that is not independently asserted in the vendor advisory but is repeated by multiple defenders citing NVISO’s evidence. The overall chronology matters to risk analysis because it indicates a long tail of potential exposure in environments where SDMP was enabled but not assumed to be a privilege boundary.

Patch guidance is explicit at the vendor layer and comprehensive at the upstream layer. The Broadcom advisory VMSA‑2025‑0015 lists fixed versions in a response matrix: Aria Operations 8.18.5, VMware Cloud Foundation Operations 9.0.1.0, and VMware Tools 13.0.5 across supported platforms, with VMware Tools 12.5.4 provided for older major lines and a special 12.4.9 build included inside the 12.5.4 bundle for 32‑bit Windows. The advisory also states there are no official workarounds, which is consistent with the exploit mechanics; because the fault is in how version discovery is implemented, any attempt to filter process names without fixing the executor risks brittle bypasses. At the same time, the upstream patch bundle for open‑vm‑tools demonstrates a pragmatic containment approach by removing the vulnerable invocation pathway in distributions that integrate it rapidly.

Independent defenders corroborated key elements that the vendor advisory did not emphasize. The Center for Internet Security advisory explicitly cites NVISO’s determination that exploitation began in mid‑October 2024 and ties the activity to UNC5174, a point absent from the vendor’s bulletin but material for organizations performing historical scoping and threat‑hunting. That advisory also enumerates affected release lines in vendor terms, offering an independent checklist that tracks to the vendor’s matrix and adds operational color for government and enterprise risk teams. In practice, this external confirmation, coupled with the upstream patch evidence and the package‑level updates from major Linux distributions, provides a triangulated picture of risk, fix, and verification steps.

From a systems perspective, the trust boundary error is stark. Aria Operations is positioned as a performance and capacity brain for virtual infrastructure, and VMware Tools is the privileged conduit that makes a guest manageable by that brain. Combining those roles with permissive regexes produced a channel where a guest user could place a binary that looks like a service, arrange for it to be listening on a socket, and wait for the management plane to come along and run it as root to learn its version. The design intent—use a generic pattern to find common services by their executable names and ask them for their version—seems innocuous until one recognizes that the selector is path‑blind and the executor inherits elevated privileges. That combination made local‑to‑root not just possible but straightforward, and NVISO’s example shows how banal the planted path could be: a file named httpd in /tmp, a faux process with a listener, and a guaranteed “‑v” call issued by the discovery routine shortly thereafter.

Two implementation details deserve emphasis because they are easy to miss but central to the root cause. First, the use of regexes like /\S+/(httpd‑prefork|httpd|httpd2‑prefork) means “match any non‑whitespace path segment followed by that executable name,” which is a perfect match for a world in which user‑writable directories are plentiful and process command lines are easy to shape. Second, the code that executes the match uses shell expansion to strip arguments and then runs the resulting binary with the requested flag, which collapses the distinction between recognizing a legitimate system path and executing any matched path. The fix strategy adopted upstream—disabling the vulnerable script path—acknowledges that safe version discovery is not a simple matter of “tightening a regex,” because any pattern‑based approach that still executes from user‑writable locations would perpetuate the privilege‑boundary error under a different mask.

Responsible handling of the disclosure is also visible in the record. NVISO’s post includes a day‑by‑day timeline from initial forensic clue to coordinated disclosure, with the embargo extended by the vendor to line up with patch train schedules and lifted on 2025‑09‑29 with the publication of Aria Operations 8.18.5 and the VMware Tools updates. The patch artifacts upstream show a matching cadence, with backports prepared for long‑term support series so that distributions do not have to jump major versions to remove the risk. In parallel, the vendor’s advisory called out a related Aria Operations credential disclosure issue as CVE‑2025‑41245, underscoring that the September 2025 maintenance releases had multiple security objectives. The CVE‑2025‑41245 entry records that separate flaw and shows why organizations should take the full maintenance update rather than attempting single‑issue remediation.

Verification steps follow directly from the mechanism. Because the exploit relies on the management plane triggering a version query against a running process that matches one of the service patterns, operators can review process trees and logs for signatures such as a privileged discovery script launching an unexpected binary with a “‑v” or “‑‑version” argument, and they can search guest filesystems for non‑system binaries whose names correspond to common services. The NVISO write‑up provides concrete examples of both the process‑tree evidence and the temporary script artifacts left by Aria Operations in credential‑based mode, and distributions that incorporated the fix by disabling the script provide a second verification vector: if a system was vulnerable and is now patched, the SDMP module no longer executes get‑versions.sh and therefore cannot produce the same child process relationships. These signals, combined with patch‑level checks that confirm a guest is on VMware Tools 13.0.5 or 12.5.4 or that the upstream patches are applied, provide a practical way to close the loop on remediation.

The broader lesson for platform engineering is to treat “version discovery” as a privileged operation that must obey the same path hygiene and execution controls as any other code launch in a root context. The affected logic assumed that identifying a binary by name was tantamount to identifying a trustworthy execution target, then implicitly trusted that binary to run with elevated privileges to print a string. That assumption collapses in environments where unprivileged users control writable directories, and it collapses doubly fast when the selector is a regular expression that matches any path segment. Safer designs would avoid executing discovered binaries at all, derive version information from package metadata or static inspection in well‑known system paths, and, when execution is unavoidable, constrain it with explicit whitelists, drop privileges, and a controlled environment. In that sense the upstream fix—removing the execution path outright—reflects a correct instinct: when a discovery feature cannot be made trustworthy under least‑privilege and trusted‑path constraints, it should be disabled until a design that meets those constraints is available.