Revisiting OMI: Analysis of CVE-2022-29149, a privilege escalation vulnerability in Azure OMI

Affected organizations are required to update installed agents that use the OMI cloud middleware software

In the last year, we invested time and effortresearching cloud middleware, the software that bridges between customers' virtual machines and cloud providers’ managed services.

As part of June 2022 Patch Tuesday, Microsoft published a patch to fix a new privilege escalation vulnerability,CVE-2022-29149inOpen Management Infrastructure (OMI), with a CVSS score of 7.8 (the highest score possible for vulnerabilities that allow local privilege escalation). OMI is cloud middleware software used by Azure, typically installed on Linux VMs without explicit customer notification, likemost other cloud agents. This is the fifth known vulnerability affecting OMI. Wiz Research found and reported the previous four vulnerabilities in June 2021, including an unauthenticated remote code execution vulnerability dubbed “OMIGOD” (CVE-2021-38647).

OMI is installed automatically by multiple popular Azure services usually as part of the OMS agent (Operations Management Suite). While it is documented by Microsoft, customers may still not be aware of its existence. This lack of awareness can lead to lower remediation rates as customers don’t address associated risks or make necessary updates. We've validated that CVE-2022-29149 is exploitable and collaborated with Azure to improve patching and customer notification processes for such issues. We thank Microsoft for the fruitful collaboration that resulted in the onboarding of OMI dependent agents (Azure’s Operations Management Suite agent,Desired State Configuration agentandAzure Diagnostics agent) to the Extension Auto-update feature of Azure. Read more about the collaboration between Wiz and Azure in ourblog.

In this post, we share technical details about the vulnerability based on our own research and provide detection and remediation instructions. Additionally, we review the cloud middleware issue and explain why it can leave cloud customers at risk.

See Microsoft’s advisory for more information and mitigation guidancehere. Wiz customers can also check the in-appThreat Center, which links directly to our detailedthreat advisory.

This latest vulnerability affects every version of OMI earlier than 1.6.9-1. According to Microsoft’s advisory, the following services currently do not support auto-updates, meaning that Linux virtual machines deployed in Azure using any of these services remain vulnerable unless updated:

OMI as standalone package

System Center Operations Manager (SCOM)

Azure Automation

Azure Automatic Update

Azure Operations Management Suite (OMS)

Azure Log Analytics

Azure Diagnostics

Azure HDInsight

Azure Container Monitoring solution

Azure Security Center

Azure Sentinel

Cloud middleware software is often silently installed by CSPs when customers onboard services. Also, cloud middleware often runs with high privileges. This combination of lack of customer awareness and high privilege access may expose customer environments in case of vulnerabilities. Software of this nature increases the attack surface of cloud environments, potentially exposing customers to local privilege escalation and remote code execution vulnerabilities. The current shared responsibility model does not clearly define who is responsible for securing cloud middleware, and as a result customers often fail to address the associated risks, leaving their environments and data vulnerable even after vulnerabilities have been disclosed and patched.

To learn more about cloud middleware and its effect on cloud customers' security posture, you can read our latestblog poston the subject.

A notable example of cloud middleware software in Azure is OMI, short for Open Management Infrastructure. It is an open-source project sponsored by Microsoft in collaboration withThe Open Group. Essentially, it is Windows Management Infrastructure (WMI) for UNIX/Linux systems. OMI allows you to gather statistics and synchronize configurations across your environment. Thanks to the ease of use and abstraction that OMI provides, it sits behind the scenes of many Azure services includingOpen Management Suite(OMS),Azure Insights,Azure Automation, and more.

Microsoft introduced a largepatchto OMI that involved multiple changes across several files, which tells us that fixing this vulnerability was not a simple task. Upon reviewing the changes, we observed that the patch included a major design change in the internal communication protocol between the various components of OMI. For one thing, the developers removed thesecretStringmechanism, which had previously been used to verify some of the most critical internal communications – so why did the developers of OMI decide to get rid of it?

secretStringis a randomly generated password used for securing communications between several of OMI’s components and verifying messages originating in the highly-privileged OMI process. You can refer to theappendix in our OMIGOD publicationto learn how we were able to manipulate OMI to elevate our privileges to root in cases where OMI did not have thissecretStringmechanism in place.

ThesecretStringis randomly generated when the OMI process is launched. But how random is it? Let’s review themethod that generates the “random” secretString:

(1) shows that the current system time serves as the seed for the randomly generated string. Since OMI generates thesecretStringupon launch, it is possible to reveal the seed, since we can find out how long the OMI process has been running. Knowing thesecretStringseed, we can predict thesecretStringand forge messages as though they were coming from the high-privileged OMI process: By replacing thetimemethod (1) in the above code snippet with the actual time at which the OMI process was launched, we can recover thesecretString.

What possibilities does this secret open? Apparently, we can use the recoveredsecretStringto bypass the patch Microsoft introduced to addressCVE-2021-38645(one of the LPE vulnerabilities we disclosed in June 2021) and elevate our privileges to root.

Following our collaboration with Microsoft on the issue, Microsoft onboarded OMS, LAD and DSC to theAutomatic Extension Upgradefeature. With this feature, these agents (and therefore also OMI, which comes bundled with them) can be updated as soon as a new version is introduced.We join Microsoft’s recommendation and urge customers toenable automatic updatesfor the OMS, LAD and DSC agents and encourage customers to migrate toAzure Monitoring Agentwhich does not rely on OMI.Automatic Extension Upgrade will ensure that Azure customers get any important security updates to the agent as soon as possible with no manual overhead, and is therefore an excellent way to mitigate the vulnerability detailed above.

Customers who do not opt in to auto-updates need to perform manual steps to patch their environment. For most Azure services, OMI can be updated using thepackage manager.

However, the CPE details for the OMI vulnerability do not specify the OMI package. Without any link between the CVE and the OMI package, the vulnerability is invisible to traditional vulnerability management tools, making it hard to track.

To assess an Azure Linux VM’s vulnerability to CVE-2022-29149, Azure customers can connect to the VM and run the commands below in the terminal to check which version (if any) of OMI is installed:

For Debian systems (e.g., Ubuntu):dpkg -l omi

For Redhat based systems (e.g., Fedora, CentOS, RHEL):rpm -qa omi

If no results return, this means OMI isn’t installed and the machine is not vulnerable. If any results are returned, you’ll see what version of OMI is installed. The patched version for the recently announced vulnerability CVE-2022-29149 is 1.6.9-1. See Microsoft’s advisory for more information and mitigation guidancehere.

Wiz has a dedicated team of researchers who track new high-profile vulnerabilities in order to provide appropriate and immediate detection for cases like this one. Thanks to their vigilance, the Threat Center started detecting vulnerable workloads the same day that CVE-2022-29149 was announced.

Wiz customers can use the Threat Center to find all affected workloads in their environment, prioritized according to effective risk, and review the in-product advisory for additional guidance.

To address the increasing risk of cloud middleware, Wiz recently launched acommunity-driven cloud middleware datasetto map all the agents that cloud providers install on customers' machines along with the additional attack surface they introduce. This GitHub page gives cloud customers the power to understand the security risks posed by certain cloud services.

Mapping all the agents that cloud providers are installing is not a trivial task. We call on the entire security community to help us achieve this ambitious goal by contributing and helping us keep this database updated.

We encourage you to check out ourGitHub page, share it with your colleagues, and help us in our effort to create a better and more secure cloud.

Finally, CVE-2022-29149 is now listed oncloudvulndb.org,a community-driven open cloud vulnerability and security issue database.

Visit our booth and attend one of our many sessions at re:Inforce this week.

Wiz leverages its leading Cloud Security Graph to help Cloud Defenders quickly understand, with the click of a button— what happened, where it happened, and how to respond.

We invite you to attend Wiz Research's four technical sessions as well as the Wiz party at Flight Club Boston.

Get a personalized demo

©2026Wiz, Inc.

StatusPrivacy PolicyTerms of UseModern Slavery StatementCookie Settings