CVE-2021-38649

What it actually does

CVE-2021-38649 is a local privilege escalation vulnerability in Microsoft Open Management Infrastructure (OMI), a Linux management agent deployed directly or indirectly by multiple Azure and Microsoft monitoring, automation, diagnostics, security, and operations-management products. A user who already has local, low-privileged access to an affected Linux system can abuse the flaw to execute privileged OMI operations and gain root-level control. Because OMI often runs as root and is installed transparently by Azure extensions, exploitation can turn an otherwise limited foothold into full host compromise, including access to sensitive files, credentials, configuration, logs, and management-plane artifacts present on the system.

Why it matters to the business

Successful exploitation can allow an attacker with an initial foothold on an affected Linux host to take full administrative control of that host, disrupt workloads, tamper with monitoring or security tooling, steal secrets, and use the host to move deeper into the environment. The issue is listed in CISA KEV, has been exploited in the wild, and the federal remediation deadline was 2021-11-17, so any remaining exposure should be treated as overdue and high priority despite the vulnerability requiring local access. The business risk is elevated because OMI is commonly installed as a dependency of widely used Azure services and agents, meaning organizations may be exposed even if they did not intentionally deploy OMI themselves.

How an attack unfolds

An attacker first obtains local code execution or a low-privileged shell on a Linux system running a vulnerable OMI package, commonly through stolen credentials, exploitation of another application, misconfigured remote access, or compromise of a workload account. The attacker then checks for OMI by looking for the omiserver process, OMI package metadata, or files under /opt/omi and /etc/opt/omi. If the installed version is vulnerable, the attacker abuses the privilege escalation condition to cause OMI, which typically runs with root privileges, to perform actions or execute code with elevated permissions. After gaining root access, the attacker can disable logging or security agents, dump credentials and tokens, access protected application data, establish persistence, and pivot to other systems. Public reporting around the broader OMI vulnerability set led to widespread scanning and opportunistic exploitation, and this specific issue is in the Known Exploited Vulnerabilities catalog, so defenders should assume unpatched internet-facing or previously compromised OMI-equipped systems may have been targeted.

How to fix it

Update Microsoft Open Management Infrastructure and any Azure or Microsoft agents/extensions that bundle or deploy it to the latest vendor-supported versions. Where package-level remediation is available, ensure OMI is updated to a patched release, commonly OMI 1.6.8.1 or later for the 2021 OMI security update line, or the latest distribution-provided Microsoft package if newer. Because OMI is often installed by Azure Automation State Configuration, Azure Automation Update Management, Azure Diagnostics for Linux, Azure Security Center/Microsoft Defender for Cloud, Microsoft Sentinel integrations, Azure Stack Hub, Container Monitoring Solution, Log Analytics Agent, and System Center Operations Manager, update the parent extension or solution as well rather than only removing files manually. If OMI is not required, remove the OMI package and dependent extensions after confirming operational impact. Restrict local shell access, enforce least privilege, rotate credentials on systems suspected of compromise, and verify that OMI management ports are not unnecessarily exposed. Although this CVE is local privilege escalation, systems affected by the broader OMI vulnerability set should also be reviewed for exposure on TCP 5985, 5986, and 1270.

How to confirm the fix worked

Confirm remediation by inventorying Linux hosts for OMI and validating the installed package version is patched. On RPM-based systems, use commands such as `rpm -q omi`; on Debian/Ubuntu-based systems, use `dpkg -l omi` or `apt list --installed omi`; and on any Linux host, check `/opt/omi/bin/omiserver --version` where available. Validate that Azure extensions or Microsoft agents that deploy OMI have also been updated to current versions. Confirm that the running omiserver binary corresponds to the updated package by restarting the service if required and checking process start time, package metadata, and file timestamps. Review network exposure and ensure OMI listeners are not reachable except where explicitly required. For assurance, run authenticated vulnerability scans or configuration checks that enumerate OMI versions rather than relying only on port scans, because this vulnerability can remain present even when OMI is not externally exposed.

Typical attack path

1. Gain low-privileged local access to a Linux host through another vulnerability, weak credentials, exposed service, or compromised workload account.
2. Identify whether Microsoft OMI is installed by checking for omiserver, omiagent, omiengine, the omi package, or OMI directories under /opt/omi, /etc/opt/omi, and /var/opt/omi.
3. Determine whether the installed OMI version predates the vendor security update.
4. Trigger the local privilege escalation condition to make the root-running OMI service perform privileged actions.
5. Obtain a root shell or equivalent administrative control on the host.
6. Collect credentials, tokens, configuration files, logs, and sensitive workload data accessible to root.
7. Modify or disable monitoring and security controls, add persistence, and use the host as a staging point for lateral movement.

How to detect it

Hunt for evidence that a low-privileged local user escalated to root through OMI or tampered with the OMI installation. Useful sources include Linux authentication logs such as /var/log/auth.log and /var/log/secure, auditd logs, EDR process telemetry, shell histories, package manager logs, systemd journal entries, OMI logs under /var/opt/omi/log, Azure extension logs, and file integrity monitoring data for OMI directories. Look for omiserver, omiagent, or omiengine spawning unexpected shells, interpreters, download utilities, user-management commands, or persistence mechanisms. Investigate root-owned files created shortly after activity by non-root users, unexpected changes to /etc/sudoers, /etc/passwd, /etc/shadow, /root/.ssh/authorized_keys, cron directories, systemd service files, and OMI binaries or configuration. Because this is a local privilege escalation issue, there may be no distinctive network signature; detection depends heavily on endpoint process lineage and local log correlation. For hosts that were also exposed to the broader OMI vulnerability set, additionally review inbound traffic to TCP 5985, 5986, and 1270, especially unauthenticated requests, unusual User-Agent values, high-volume scanning, or requests followed by suspicious root-level process activity.

• /opt/omi/bin/omiserver
• /opt/omi/bin/omiagent
• /opt/omi/bin/omiengine
• /etc/opt/omi/conf/omiserver.conf
• /var/opt/omi/log/omiserver.log
• /var/opt/omi/log/omiagent.root.root.log
• /var/opt/omi/log/omiengine.log
• omiserver
• omiagent
• omiengine
• rpm -q omi
• dpkg -l omi
• /var/log/azure/Microsoft.EnterpriseCloud.Monitoring.OmsAgentForLinux/
• /var/log/azure/Microsoft.Azure.Diagnostics.LinuxDiagnostic/
• /var/opt/microsoft/omsagent/
• /etc/systemd/system/omi.service
• /lib/systemd/system/omi.service
• /usr/lib/systemd/system/omi.service
• TCP/5985
• TCP/5986
• TCP/1270
• /etc/sudoers
• /etc/sudoers.d/
• /root/.ssh/authorized_keys
• /etc/cron.d/
• /etc/systemd/system/

What your security team should do

• Treat all remaining vulnerable OMI installations as urgent because the vulnerability is in CISA KEV, has active in-the-wild exploitation history, and the remediation due date has long passed.
• Create an enterprise-wide inventory of Linux systems running OMI, including systems where OMI was installed indirectly by Azure monitoring, automation, diagnostics, security, or operations-management extensions.
• Patch or upgrade OMI and parent Microsoft/Azure agents to the latest supported versions; remove OMI where it is not required.
• Prioritize systems that are internet-facing, host sensitive workloads, run privileged automation, or have evidence of prior compromise.
• Hunt for historical signs of local privilege escalation, suspicious root process creation, unauthorized account or SSH key creation, and tampering with OMI logs or binaries.
• Review exposure to related OMI vulnerabilities, especially systems listening on TCP 5985, 5986, or 1270.
• Restrict local login rights and service-account permissions on Linux hosts running management agents.
• Rotate credentials, secrets, and tokens stored on or accessible from hosts where exploitation is suspected.
• Ensure endpoint telemetry captures process lineage for omiserver, omiagent, omiengine, shell execution, package changes, and privilege changes.
• Document OMI ownership and update responsibility so future Azure extension or agent deployments do not silently reintroduce outdated packages.