CVE-2025-41244

What it actually does

This is a local privilege escalation flaw in the VMware Tools / VMware Aria Operations integration path when a Linux VM is managed by Aria Operations with SDMP enabled. A user who already has non-administrative local access to the guest VM can abuse unsafe privileged actions exposed through that management/tooling workflow to gain root privileges on the same VM. The vulnerability does not provide initial remote access by itself, but it can turn a low-privilege shell, compromised service account, or foothold inside a VM into full guest operating system control.

Why it matters to the business

An attacker who has already obtained basic access to an affected VM can take full control of that VM, disable security tooling, steal data, dump credentials, alter workloads, and use the system as a staging point for lateral movement. Because this vulnerability is in the CISA Known Exploited Vulnerabilities catalog, has active in-the-wild exploitation reporting, and is associated with UNC5174 activity, remediation should be treated as urgent even though exploitation requires local access. Organizations subject to KEV-based remediation requirements should note the listed CISA due date of 2025-11-20 has passed. The provided package data also suggests potentially broad Linux estate relevance where affected Debian 12/13 or related stable-kernel builds are present.

How an attack unfolds

An attacker first obtains non-administrative access to a Linux VM, commonly through stolen credentials, exploitation of an application vulnerability, exposed remote access, or post-compromise lateral movement. The attacker then checks whether VMware Tools is installed and whether the VM is managed by VMware Aria Operations with SDMP enabled. If the vulnerable configuration is present, the attacker invokes or manipulates the affected VMware Tools / Aria Operations privileged action flow so that an operation intended to run with elevated permissions is performed unsafely. Successful exploitation results in root privileges inside the guest VM. From there, the attacker can install persistence, tamper with logs and defenses, access sensitive files, harvest credentials, and pivot to other systems reachable from the compromised VM. Public reporting indicates active exploitation in the wild, including activity tracked in relation to UNC5174, so post-exploitation review should assume this may be chained after an initial-access vulnerability or credential compromise.

How to fix it

Patch VMware Aria Operations and VMware Tools according to the relevant Broadcom/VMware advisory for this vulnerability, prioritizing Linux VMs where VMware Tools is installed and Aria Operations SDMP is enabled. If immediate patching is not possible, disable SDMP or remove the vulnerable management integration where operationally feasible, restrict local shell access to affected VMs, and monitor for suspicious privilege escalation activity. For the package versions supplied with this record, update Debian 12 and Debian 13 linux packages to version 6.1.11-1 or later, and ensure source-based deployments include stable Linux commit 567128076d554e41609c61b7d447089094ff72c5 or a later fixed revision. Because the affected-product metadata appears to combine VMware product context with Linux kernel package data, validate exposure against the authoritative vendor advisory and the actual installed VMware Tools, Aria Operations, and OS package versions in the environment.

How to confirm the fix worked

Confirm that affected VMs have updated VMware Tools and that VMware Aria Operations is at a fixed vendor-supported release. Validate whether SDMP is enabled and, if not required, confirm it is disabled. On Linux systems, verify installed package versions using the native package manager, such as dpkg-query or apt policy on Debian-based systems, and confirm Debian 12/13 linux packages are at 6.1.11-1 or later where that package lineage applies. For source-managed kernels, verify the build includes commit 567128076d554e41609c61b7d447089094ff72c5 or a later fixed commit. Reboot VMs if required for VMware Tools, kernel, or service updates to take effect. After remediation, confirm vmtoolsd and related VMware services are running the expected fixed versions and review Aria Operations inventory to ensure no managed VM remains in the vulnerable SDMP-enabled state.

Typical attack path

1. Gain low-privilege local access to a Linux VM through credentials, application compromise, or lateral movement.
2. Identify that VMware Tools is installed and running on the VM.
3. Determine whether the VM is managed by VMware Aria Operations with SDMP enabled.
4. Trigger the vulnerable privileged action path exposed by the VMware Tools / Aria Operations SDMP workflow.
5. Escalate from a non-administrative user context to root on the same guest VM.
6. Use root access to collect credentials, disable defenses, establish persistence, access sensitive data, or move laterally.

How to detect it

Hunt for evidence that a low-privilege local account became root on Linux VMs running VMware Tools and managed by Aria Operations with SDMP enabled. Relevant sources include Linux authentication logs, auditd logs, sudo/su logs, process execution telemetry, EDR events, shell history, systemd journal logs, VMware Tools logs, Aria Operations task/activity logs, and file integrity monitoring. Look for unusual execution of VMware Tools processes or helper utilities by non-administrative users, unexpected root shells spawned soon after vmtoolsd or VMware management actions, modifications to privileged files, new setuid binaries, new systemd services, suspicious cron entries, unauthorized SSH keys, disabled security agents, and log clearing. Correlate suspected privilege escalation with prior initial-access indicators such as anomalous SSH logins, web application exploitation, new local users, reverse shells, or unexpected outbound connections. Because public technical exploit artifacts may vary and this vulnerability has active in-the-wild exploitation reporting, absence of a single signature is not sufficient; prioritize behavioral detection around local privilege escalation and post-exploitation changes on exposed VMs.

• vmtoolsd
• /usr/bin/vmtoolsd
• /usr/sbin/vmtoolsd
• /var/log/vmware-vmsvc.log
• /var/log/vmware-vmsvc-root.log
• /var/log/vmware-network.log
• /var/log/vmware-vgauthsvc.log
• vgauthd
• vmware-vmsvc
• SDMP
• sdmp
• /etc/sudoers
• /etc/sudoers.d/
• /etc/passwd
• /etc/shadow
• /root/.ssh/authorized_keys
• /etc/systemd/system/
• /var/spool/cron/
• /etc/cron.d/
• /tmp/.X11-unix/
• /dev/shm/
• chmod u+s
• setuid
• COMMAND=/usr/bin/vmtoolsd
• session opened for user root
• sudo:
• su: pam_unix(su:session): session opened for user root

What your security team should do

• Immediately inventory Linux VMs with VMware Tools installed and identify which are managed by VMware Aria Operations with SDMP enabled.
• Prioritize remediation for internet-facing workloads, privileged administration hosts, systems containing sensitive data, and VMs where low-privilege users or application service accounts can obtain shell access.
• Apply the relevant VMware/Broadcom fixes for Aria Operations and VMware Tools; where the supplied package metadata applies, update Debian 12/13 linux packages to 6.1.11-1 or later.
• Disable SDMP or the vulnerable management integration as a temporary mitigation if patching cannot be completed quickly.
• Treat this as an actively exploited vulnerability because it is KEV-listed and associated with in-the-wild exploitation reporting, including UNC5174-related activity.
• Hunt for recent privilege escalation from non-root users to root on affected VMs, especially following suspicious logins, web-shell activity, or exploitation of other services.
• Review root-owned files, persistence mechanisms, scheduled jobs, systemd units, SSH authorized_keys files, and security-tool tampering on affected systems.
• Segment and restrict management-plane access between Aria Operations, VMware Tools-managed VMs, and administrative networks.
• Ensure endpoint detection, auditd, Linux authentication logging, and VMware Tools logs are retained long enough to cover the suspected exposure window.