CVE-2021-38645

What it actually does

CVE-2021-38645 is a local privilege escalation flaw in Microsoft Open Management Infrastructure (OMI). A user who already has low-privileged local access to an affected Linux system can abuse OMI behavior to gain elevated privileges, potentially root-level control. Because OMI is often installed as an agent dependency for cloud management and monitoring extensions, vulnerable systems may not have been intentionally deployed with OMI by administrators. The provided package metadata also references cve-search/cve-search Git content fixed at commit c621f9f0693a728b93ff3b964f948a1d25917207; environments using that package lineage should validate and update to that fixed commit or later.

Why it matters to the business

Successful exploitation can turn a limited foothold on a Linux server into full administrative control, enabling data theft, tampering, persistence, lateral movement, service disruption, and deployment of additional malware. This issue is in the CISA Known Exploited Vulnerabilities catalog and has been observed exploited in the wild, so remediation should be treated as overdue and high priority, especially for internet-facing, cloud-hosted, or management-agent-heavy Linux fleets.

How an attack unfolds

An attacker first obtains low-privileged access to a vulnerable Linux host through stolen credentials, exploitation of a separate service, malicious code execution, or misuse of an application account. After confirming that OMI is installed and running, the attacker interacts with local OMI components or management interfaces in a way that triggers the privilege escalation condition. If exploitation succeeds, the attacker gains elevated privileges, commonly equivalent to root, and can then create persistence, read sensitive files, modify system configuration, disable security tooling, harvest credentials, or use the host as a pivot point. In real-world intrusions this vulnerability is especially concerning when chained after remote code execution or credential compromise because it removes the boundary between an initial low-privileged shell and full host compromise.

How to fix it

Patch affected OMI deployments immediately. Update Microsoft Open Management Infrastructure to a version containing the September 2021 security fixes or later, and ensure cloud management extensions that bundle OMI are also updated or redeployed. Where the supplied package metadata applies, update cve-search/cve-search Git deployments to commit c621f9f0693a728b93ff3b964f948a1d25917207 or later. If immediate patching is not possible, reduce exposure by removing unused OMI components, disabling the OMI service where operationally safe, restricting local interactive and service-account access, hardening sudo and service permissions, and increasing monitoring for local privilege escalation behavior. Because this CVE is in the CISA KEV catalog with a remediation deadline of 2021-11-17, any remaining vulnerable instances should be treated as an exception requiring urgent remediation tracking.

How to confirm the fix worked

Confirm whether OMI is installed by checking package inventories, running services, and filesystem paths such as /opt/omi and /var/opt/omi. Verify the installed OMI version is at or above the vendor-fixed release containing the September 2021 fixes, and confirm that cloud extensions or agents that may reinstall OMI have also been updated. For the listed Git package metadata, verify the deployed revision is c621f9f0693a728b93ff3b964f948a1d25917207 or later. Validate that the OMI service has been restarted after patching and that no outdated OMI binaries remain on disk. Where vulnerability scanners are used, run authenticated scans against Linux hosts because local package and file checks are more reliable than network-only detection for this privilege escalation issue.

Typical attack path

1. Gain low-privileged local access to a Linux host through another vulnerability, stolen credentials, or compromised application context.
2. Enumerate installed agents, packages, services, and processes to determine whether OMI is present and vulnerable.
3. Interact with the local OMI service or related management components to trigger the privilege escalation flaw.
4. Obtain elevated privileges, typically root-level execution.
5. Establish persistence, access sensitive files, modify configurations, or disable defenses.
6. Use the compromised host for lateral movement, credential theft, data access, or additional payload deployment.

How to detect it

To determine whether exploitation already occurred, review Linux authentication logs, shell history, process accounting, EDR telemetry, OMI logs, package installation history, and file integrity data. Focus on evidence that a low-privileged account performed actions followed closely by root-level command execution, new user creation, SSH key modification, sudoers changes, service changes, or security tool tampering. Check OMI-related logs under /var/opt/omi/log and system logs for unexpected OMI activity, crashes, restarts, or management operations. Review process lineage for shells, scripting interpreters, download utilities, or persistence commands executed by or near OMI processes. Because this is a local privilege escalation vulnerability, the strongest signs are often post-exploitation artifacts rather than a single network signature. If this issue was chained with remote OMI exploitation, also review inbound WSMan/OMI traffic to TCP ports 5985 and 5986 and HTTP requests to /wsman.

• /opt/omi/bin/omiserver
• /opt/omi/bin/omiagent
• /var/opt/omi/log/omiserver.log
• /var/opt/omi/log/omiagent.log
• /etc/opt/omi/conf/omiserver.conf
• omiserver
• omiagent
• POST /wsman
• TCP/5985
• TCP/5986
• /etc/sudoers.d/
• /root/.ssh/authorized_keys
• useradd
• adduser
• chmod u+s
• setcap cap_setuid+ep

What your security team should do

• Prioritize immediate remediation for all Linux systems with OMI installed, especially cloud VMs, management servers, and systems where a separate vulnerability could provide an initial foothold.
• Perform authenticated fleet inventory for OMI packages, services, and files; do not rely only on whether administrators intentionally installed OMI.
• Patch or redeploy affected OMI-based cloud extensions and verify that patched agents do not reinstall vulnerable OMI builds.
• Hunt for post-exploitation behavior, including suspicious root shells, new privileged users, modified SSH keys, credential access, and unexpected processes spawned around OMI activity.
• Apply least-privilege controls to local users, service accounts, and automation accounts to reduce opportunities for local exploitation.
• If patching cannot be completed immediately, disable or remove OMI where not required and monitor affected hosts continuously until remediated.
• Treat any confirmed exploitation as full host compromise and perform incident response actions including credential rotation, persistence review, and lateral movement investigation.