CISA’s required action for CVE-2022-22960 is to apply updates per vendor instructions. In practice, find every instance of VMware Multiple Products in your estate, apply the vendor security update or documented mitigation, and if no fix can be applied, remove internet exposure or take the product out of service. After patching, review logs for signs of earlier exploitation, because attackers used this flaw in the wild.
What the fix looks like in practice for CVE-2022-22960
The safest starting point is the vendor-directed remediation path already called out by CISA, then verify that every exposed VMware instance is covered. For an exploited issue like this, Zero-Day and Exploited Vulnerabilities Guide is the right operating model: confirm asset scope, treat the flaw as an active-exploitation event, and complete patching or mitigation before returning the product to normal exposure.
In practical terms, this means you should inventory all VMware Multiple Products instances, apply the vendor security update or documented mitigation, and avoid assuming a partial rollout is good enough. If a system cannot be fixed quickly, remove internet exposure or take it out of service until the vendor path is complete. That is a containment decision, not a long-term state.
If you need to prioritise among multiple vulnerable systems, use vulnerability-management discipline rather than ad hoc triage. Vulnerability Management Guide supports the right sequence here: identify scope, prioritise exploited exposure first, track exceptions explicitly, and validate that remediation actually landed.
Why exposed VMware systems need more than a patch ticket
CVE-2022-22960 matters because privilege-escalation flaws turn a foothold into broader control, especially when the target is externally reachable or centrally managed. The main risk is not just that the bug exists, but that an attacker can use it to move from ordinary access to elevated access before defenders notice. If the product is reachable from the internet, the exposure is materially worse.
Patch delay also creates a detection problem. Once a privilege-escalation flaw has been exploited, the attacker may leave behind altered configuration, new credentials, or persistent access paths that survive the fix. That is why post-patch review is part of remediation, not an optional follow-up.
Failure mechanism: The vulnerability provides a route to higher privileges on affected VMware products, which can let an attacker bypass normal access boundaries and operate with administrative or near-administrative control.
Impact: The likely consequence is expanded access, stronger persistence options, and a wider blast radius if the system was already touched during exploitation.
How to validate containment and recovery after remediation
After the update or mitigation is applied, validate two things: the vulnerable service is no longer exposed in the way that enabled the flaw, and there is no sign of earlier compromise. For exploited vulnerabilities, CISA Known Exploited Vulnerabilities Catalog is the right reference point for treating the issue as confirmed in the wild, which should drive faster verification and tighter exception handling.
Review logs around the exposure window for privilege changes, unexpected admin activity, new accounts, unusual authentications, or changes to supporting services. If the VMware product was used as an entry point, assume the attacker may have tried to use it as a staging point for broader access, not just as a single isolated host.
Where the system was likely exposed to live exploitation, consider whether adjacent secrets, sessions, or privileged credentials should be rotated as part of the cleanup. That decision is material when the compromised product could have handled administrative workflows or stored access material that would make follow-on access easier.
Risk and Threat Considerations
Privilege-escalation bugs in management platforms are attractive because they compress the attack path: a single weakness can turn limited access into control over a broader environment. The practical threat is highest when the vulnerable product is internet-facing, widely deployed, or trusted by other internal systems.
Failure mechanism: An attacker exploits the flaw to elevate privileges, then uses that elevated position to persist, inspect configuration, or pivot into neighbouring systems and administrative functions.
Impact: The result can be lateral movement, persistence, and compromise of higher-value assets that were not directly vulnerable themselves.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK addresses the attack and risk surface, while CIS Controls v8, NIST SP 800-53 Rev 5 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| CIS Controls v8 | CIS-7 — Continuous Vulnerability Management | Tracks exploited flaws through prioritised remediation and validation. |
| Recommendation — Prioritise and verify remediation of exploited VMware instances before returning them to service. | ||
| NIST SP 800-53 Rev 5 | SI-2 — Flaw Remediation | Requires timely installation of security updates and mitigation of known flaws. |
| AU-6 — Audit Record Review, Analysis, and Reporting | Supports log review after suspected exploitation for signs of compromise. | |
| Recommendation — Apply the vendor update or mitigation and document exception handling until fixed. Review authentication and administrative logs for evidence of earlier exploitation. | ||
| NIST CSF 2.0 | PR.IP-12 — Vulnerability management plan | Covers prioritised handling of known vulnerabilities and exceptions. |
| Recommendation — Use a vulnerability-management process to triage, remediate, and track exposed VMware systems. | ||
| MITRE ATT&CK | T1068 — Exploitation for Privilege Escalation | Matches the attack objective in this CVE, privilege escalation after exploitation. |
| Recommendation — Map detection and hunting to privilege-escalation activity and follow-on persistence. | ||
Practitioner Guidance
What to prioritise: Patch every exposed instance first, then focus on any system that was reachable from the internet or handled privileged administration. If you must defer the fix, treat the exception as a time-bounded containment problem and remove exposure instead of leaving the flaw open.
What to verify: Confirm the vendor update or mitigation actually changed the vulnerable deployment, then check whether the product was touched before remediation. A patch without compromise review leaves an important gap, because the exploit may already have been used.
Decision rule: If you cannot patch immediately, isolate the system, reduce reachability, and increase monitoring before resuming service. If logs or behavioural evidence suggest abuse, move straight to incident response and credential review rather than treating the event as a routine maintenance task.
Practitioner takeaway: For an actively exploited escalation flaw, successful remediation means both removing the vulnerability and proving the environment was not already used to gain a stronger foothold.
Related resources from NHI Mgmt Group
- How do you patch or mitigate CVE-2018-19323 (GIGABYTE Multiple Products Privilege Escalation)?
- CVE-2022-22960 (VMware Multiple Products Privilege Escalation)
- How do you patch or mitigate CVE-2022-26923 (Microsoft Active Directory Domain Services Privilege Escalation)?
- How do you patch or mitigate CVE-2024-38813 (VMware vCenter Server Privilege Escalation)?