CVE-2022-22960

What it actually does

This is a local privilege escalation flaw in VMware Workspace ONE Access, VMware Identity Manager, and vRealize Automation caused by improper permissions on support scripts. A user or process that already has low-privileged local access to an affected appliance can abuse those scripts to execute commands with elevated privileges, potentially obtaining root control. The CVSS vector is local, low complexity, low privilege required, no user interaction, with high confidentiality, integrity, and availability impact.

Why it matters to the business

If an attacker first gains a foothold on an affected VMware identity or automation appliance, this vulnerability can turn limited access into full system control. Because these products often participate in authentication, identity federation, access management, and automation workflows, root compromise can lead to credential theft, service disruption, persistence, tampering with identity infrastructure, and expansion into connected systems. This issue is in CISA KEV with active exploitation reported and had a federal remediation due date of 2022-05-06, so any remaining exposure should be treated as urgent even though the vulnerability is older.

How an attack unfolds

An attacker must already be able to execute code or commands locally on the affected appliance, either through valid low-privileged credentials, a web application compromise, exploitation of another vulnerability, or post-compromise access. Once local access is obtained, the attacker identifies VMware support scripts with unsafe ownership, permissions, or execution behavior. They manipulate the vulnerable script path, arguments, environment, writable files, or helper components so that the support script runs attacker-controlled commands with elevated privileges. Successful exploitation gives the attacker root-level access, after which they can read sensitive configuration, dump credentials or tokens, modify services, install persistence, disable security controls, and use the appliance as a pivot point. In real intrusions, this class of issue is commonly chained after initial access vulnerabilities affecting VMware appliances.

How to fix it

Apply the vendor-supported fixed version or workaround for VMware Workspace ONE Access, VMware Identity Manager, and vRealize Automation as applicable. Because this is a KEV-listed vulnerability with active exploitation history, prioritize replacement or patching of any still-running affected appliances. Where package metadata maps the affected component to org/pub/scm/linux/kernel/git/torvalds/linux.git, ensure builds include fixed commit 1c163f4c7b3f621efff9b28a47abb36f7378d783; however, for VMware appliance remediation, follow the relevant VMware security advisory and product-specific update path rather than relying solely on upstream source metadata. If immediate patching is not possible, restrict administrative and shell access to trusted management networks, remove unnecessary local accounts, enforce least privilege, monitor for unexpected local command execution, and isolate the appliance from nonessential systems until remediated. After patching, rotate credentials and secrets stored on or used by the appliance if compromise is suspected.

How to confirm the fix worked

Confirm the product name, appliance version, build number, and applied hotfix level against VMware’s advisory for this vulnerability. Validate that affected support scripts are no longer writable or controllable by unprivileged users and that their ownership and permissions match the fixed vendor baseline. Review local users and sudoers configuration to ensure no unauthorized privileged accounts or sudo rules were added before or during remediation. Where source or package provenance is tracked, confirm the fixed commit 1c163f4c7b3f621efff9b28a47abb36f7378d783 is present for the listed package metadata. Run authenticated vulnerability scanning or configuration assessment against appliances and verify the scanner reports the vulnerability as remediated. Finally, test that low-privileged local users cannot modify, replace, or influence VMware support scripts to execute commands as root.

Typical attack path

1. Gain initial access to the affected VMware appliance through credentials, another vulnerability, or an existing foothold.
2. Obtain a low-privileged local shell or command execution context on the appliance.
3. Enumerate VMware support scripts, file permissions, writable directories, service accounts, and sudo or root-executed helper behavior.
4. Abuse the improper script permissions or execution flow to cause attacker-controlled code to run as root.
5. Establish root-level shell access or create a privileged persistence mechanism.
6. Collect sensitive files, tokens, credentials, logs, and configuration from the appliance.
7. Use the compromised appliance to disrupt identity services, tamper with authentication infrastructure, or pivot to connected systems.

How to detect it

Look for evidence that a low-privileged local user or web service account executed VMware support scripts shortly before a root shell, new privileged account, sudoers modification, service change, cron job, or outbound network connection appeared. Relevant sources include Linux auditd logs, /var/log/auth.log or /var/log/secure, sudo logs, shell history for local service and admin accounts, systemd journal, cron logs, VMware appliance application logs, EDR telemetry, file integrity monitoring, and process execution records. Investigate executions where parent processes are web service, application server, SSH, or low-privileged user contexts and child processes include shells, interpreters, user-management commands, chmod/chown, file writes under privileged paths, or network tools. Search for unexpected permission changes on VMware support directories and scripts, recently modified files owned by root but writable by non-root users, new setuid binaries, added SSH keys, new local users, modified sudoers files, and persistence under cron or systemd. Because this is a local privilege escalation, successful exploitation may not generate a unique network signature; detection depends heavily on endpoint and appliance telemetry. In environments that had other VMware appliance vulnerabilities exposed, correlate initial web exploitation timestamps with subsequent local privilege escalation artifacts.

• /etc/sudoers
• /etc/sudoers.d/
• /etc/passwd
• /etc/shadow
• /root/.ssh/authorized_keys
• /etc/cron.d/
• /var/spool/cron/
• /etc/systemd/system/
• /var/log/auth.log
• /var/log/secure
• /var/log/audit/audit.log
• sudo:
• COMMAND=/bin/bash
• COMMAND=/bin/sh
• useradd
• usermod
• chmod u+s
• chmod 4755
• chown root
• /opt/vmware/
• Workspace ONE Access
• VMware Identity Manager
• vRealize Automation

What your security team should do

• Immediately inventory VMware Workspace ONE Access, VMware Identity Manager, and vRealize Automation appliances and identify any versions subject to this vulnerability.
• Patch or upgrade affected appliances using VMware-supported fixed releases or hotfixes; treat unpatched systems as high priority because the issue is KEV-listed and exploitation has been observed in the wild.
• Assume this flaw may have been chained with separate initial-access vulnerabilities; do not limit investigation to local logins only.
• Restrict SSH, console, and administrative access to hardened management networks and named administrative users.
• Review support script permissions, sudoers entries, local users, cron jobs, systemd units, and startup scripts for unauthorized changes.
• Collect and preserve logs before remediation where compromise is suspected, because patching or appliance replacement may remove forensic artifacts.
• Rotate local credentials, service account secrets, SAML signing material, API tokens, and integration credentials if there are signs of appliance compromise.
• Deploy host-based monitoring for unexpected root shells, suspicious script execution, privilege changes, and outbound connections from identity or automation appliances.
• If the appliance cannot be patched promptly, isolate it, limit exposure, and plan emergency replacement or decommissioning.