Is CVE-2021-38645 (Microsoft Open Management Infrastructure (OMI) Privilege Escalation) being exploited in the wild?

Yes. CISA added CVE-2021-38645 to its Known Exploited Vulnerabilities catalogue on 3 November 2021, which it does only when there is reliable evidence of active exploitation. CISA has not linked it to known ransomware campaigns. Microsoft Open Management Infrastructure (OMI) within Azure VM Management Extensions contains an unspecified vulnerability that allows for privilege escalation. Any organisation running the affected product should treat remediation as urgent.

How to confirm the exposure quickly

The practical question is not whether the CVE exists, but whether your environment still runs Microsoft Open Management Infrastructure through Azure VM Management Extensions and is exposed to the privilege-escalation path CISA has already marked as actively exploited. Treat the KEV listing as a current exploitation signal, not a theoretical severity score. For a fast triage workflow, use the CISA Known Exploited Vulnerabilities Catalog alongside the vendor advisory, then map the vulnerable component to your asset inventory.

Because the issue is about privilege escalation, the key exposure question is whether the affected OMI component can be reached from systems that matter operationally, especially Azure-connected hosts with management extensions in place. That is where a broad vulnerability list becomes a concrete incident-prevention task. NHIMG’s Vulnerability Management Guide is useful here because it focuses on asset scope, KEV triage, and remediation verification rather than generic scanning.

What remediation should look like when the vulnerability is being exploited

For an actively exploited privilege-escalation bug, remediation should be treated as urgent patching or vendor-directed mitigation, not as routine backlog work. The right response is to verify affected hosts, apply the vendor fix or mitigation as soon as practical, and confirm that the vulnerable OMI path is no longer present. If the environment is business-critical, isolate or restrict the impacted systems until the change is complete.

When the vendor fix cannot be applied immediately, the priority is reducing reachable attack surface and limiting what an attacker could do after gaining the initial foothold. That means tightening access to the affected management plane, reviewing any automation or extension rights tied to the host, and increasing monitoring for privilege change on the exposed systems. The Zero-Day and Exploited Vulnerabilities Guide is the strongest internal reference for handling the KEV-driven response pattern that this CVE represents.

What to check after patching or mitigation

Because exploitation was active enough for CISA to list the CVE, patching alone is not a complete closure step. Check for evidence of earlier compromise on the host and on adjacent systems that the host could reach after privilege escalation. Review administrative activity, unusual process creation, suspicious extension behavior, and any unexpected changes to local or cloud-facing credentials used by the machine or its management path.

If there is any sign that the flaw was used before remediation, expand the review to downstream access and persistence opportunities. A privilege-escalation flaw often becomes useful only after the attacker has established a foothold, so the question is whether that foothold was already used to alter identities, install tooling, or stage lateral movement. NHIMG’s Ultimate Guide to NHIs, Key Challenges and Risks helps frame why unmanaged credentials and overprivilege become the real blast-radius problem once a host-level flaw is abused.

Risk and Threat Considerations

An exploited privilege-escalation vulnerability matters because it converts one compromised foothold into broader system control. In cloud-connected environments, that can expose management extensions, local administrative surfaces, and any secret material or service access available to the higher-privileged context.

Failure mechanism: An attacker gains initial code execution or local foothold on a vulnerable host, then uses the OMI weakness to elevate privilege and expand control over the managed environment.

Impact: The result can be host takeover, credential exposure, lateral movement, and broader cloud or tenant compromise if the elevated context reaches other trusted services.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

MITRE ATT&CK and OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST CSF 2.0, NIST SP 800-53 Rev 5 and CIS Controls v8 set the governance and control requirements practitioners need to meet.

Framework	Control / Reference	Relevance
NIST CSF 2.0	ID.RA-01 — Asset vulnerabilities are identified and documented	The question requires confirming whether the vulnerable OMI exposure exists in the environment.
	PR.PS-05 — Installation and execution of unauthorized software are prohibited	Actively exploited host vulnerabilities require hardening the affected management surface.
Recommendation — Identify affected assets and document exposure before you treat the CVE as remediated. Restrict the affected management component and remove unsupported or unnecessary execution paths.
NIST SP 800-53 Rev 5	RA-5 — Vulnerability Monitoring and Scanning	This CVE requires confirming exposure and validating remediation status.
Recommendation — Continuously scan for the vulnerable OMI component and verify remediation.
CIS Controls v8	CIS-7 — Continuous Vulnerability Management	KEV-listed exploitation directly maps to prioritised vulnerability handling.
Recommendation — Prioritize and remediate the exploited CVE immediately across all affected assets.
MITRE ATT&CK	T1068 — Exploitation for Privilege Escalation	The CVE is specifically a privilege-escalation vulnerability.
	T1055 — Process Injection	Post-exploitation tradecraft may include execution and stealth after escalation.
	T1078 — Valid Accounts	Privilege escalation often leads to abuse of legitimate credentials and access.
Recommendation — Hunt for privilege-escalation activity and trace the initial access path. Monitor for suspicious process behavior that follows a privileged compromise. Check whether elevated access was converted into use of legitimate accounts.
OWASP Non-Human Identity Top 10	NHI-05 — Overprivileged NHI	The CVE can expose management credentials and rights that are broader than needed.
	NHI-07 — Long-Lived Secrets	Post-exploitation risk increases when exposed credentials or tokens are long-lived.
	NHI-01 — Improper Offboarding	A compromised management path may leave stale access in place after remediation.
Recommendation — Remove excess privileges from service and management identities that could be abused after escalation. Rotate long-lived secrets that the vulnerable host could expose or reach. Revoke stale access paths and credentials tied to the affected management surface.

Practitioner Guidance

What to prioritise: Treat KEV-listed exploitation as a remediation queue override. Validate whether any Azure VM Management Extensions deployment still exposes the vulnerable OMI component, then patch or mitigate before lower-risk vulnerability work.

What to verify: Confirm that patching removed the vulnerable condition and that no privileged account, extension, or management credential on the host was used to spread further. If the host was internet-reachable or highly privileged, raise the bar for compromise assessment.

Practitioner takeaway: For KEV-listed privilege-escalation flaws, the right decision is usually to assume exposure first, then prove otherwise with inventory, patch status, and compromise checks, because waiting for confirmed abuse is exactly how these issues become incidents.