OMIGOD: an unauth root RCE in an agent you didn't know Azure installed
CVE-2021-38647 is an unauthenticated remote code execution as root in the OMI agent. Most victims didn't know they were running OMI, Azure silently deployed it on Linux VMs when you enabled common services. Invisible agents are invisible attack surface.
CVE-2021-38647, nicknamed OMIGOD, is an unauthenticated remote code execution as root, and the most striking thing about it is that most affected customers had no idea they were running the vulnerable software. The bug is in OMI (Open Management Infrastructure), a Linux management agent. Azure silently installed OMI on customers’ Linux virtual machines when they enabled common services like Log Analytics, Azure Automation, or certain monitoring and configuration features. So organizations ended up with a root-privileged agent listening on a network port that they never chose to deploy, never inventoried, and didn’t know to patch. Wiz, which found it, reported it was one of the most widespread cloud-agent exposures they’d seen.
What the bug is
OMI’s authentication had a logic flaw: when a request arrived without an Authentication header, instead of rejecting it, OMI treated it as coming from a trusted, authenticated source, and executed it as root. So an attacker who could reach the OMI port (notably 5986/5985/1270 when exposed) simply sent a request with no auth header and got root command execution. CVSS 9.8. Microsoft patched OMI in September 2021, and CISA added it with the ransomware flag. Exploitation, including by Mirai-style botnets, followed quickly against internet-exposed OMI ports.
The lesson: invisible agents are invisible attack surface
OMIGOD’s real lesson is about the cloud’s silent-agent problem. When you enable a managed cloud service, the platform often installs helper agents on your VMs to make the feature work, monitoring, logging, configuration, patch management. Those agents run with high privileges, sometimes listen on the network, and are deployed without an explicit “we are installing this software on your machine” decision you’d track. The result is attack surface you don’t know you have:
- You can’t patch what you don’t know is installed. OMI wasn’t in most customers’ software inventories, so when the CVE landed, many didn’t know they were affected.
- Agent privileges and listeners are easy to overlook. A root agent listening on a port is exactly what an attacker wants, and it’s invisible if you’re only inventorying the software you deliberately installed.
- The cloud provider’s convenience features expand your attack surface. Enabling a monitoring feature shouldn’t be assumed to be free; it may deploy privileged software you now own the risk for.
What to do
- Patch OMI to the fixed version (1.6.8-1 or later) on any affected Linux VM. Microsoft pushed updates and updated the extensions that bundle OMI; verify your VMs actually received the fix.
- Inventory cloud agents on your VMs. Enumerate what’s actually installed and listening, OMI, and the broader set of monitoring/automation/management agents your cloud services deploy. You can’t manage exposure you can’t see.
- Restrict the OMI ports. OMI’s management ports should never be reachable from the internet; ensure network security groups/firewalls block them from untrusted networks. Internet-exposed OMI was the worst case.
- Treat “enable this feature” as a software-deployment decision. When you turn on a cloud service that installs agents, account for the agents in your patch and inventory processes.
- Assume compromise on internet-exposed, unpatched OMI from the 2021 window and hunt for the root-context exploitation and botnet payloads.
The reframe is to extend your asset inventory to the software your cloud platform installs on your behalf. OMIGOD was an unauthenticated root RCE in an agent that landed on huge numbers of Linux VMs silently, which meant the exposure was invisible until someone made it visible. Inventory your cloud agents, lock down their listeners, patch them, and treat enabling a managed feature as the software install it really is. We flag the cloud-agent entries because they’re the attack surface that arrives without anyone deciding to deploy it.
Sources
Share
Related field notes
-
BlueKeep: the wormable RDP bug Microsoft patched Windows XP for
CVE-2019-0708 was a pre-authentication, wormable RCE in Windows Remote Desktop. Microsoft was scared enough of a WannaCry repeat that it shipped patches for end-of-life XP and Server 2003. The worm never fully came, but the lesson did: RDP doesn't belong on the internet.
-
The year on-premise Exchange became the most-attacked software on earth
ProxyLogon and ProxyShell turned 2021 into open season on Exchange Server. Two unauthenticated RCE chains, tens of thousands of web-shelled servers, an FBI operation to clean them up. If you still run Exchange on-prem, you're operating a permanent top-tier target.
-
A mitigation blocks a path. OWASSRF found another door.
After ProxyNotShell, Microsoft told Exchange admins to apply URL-rewrite mitigations while the patch was finished. OWASSRF (CVE-2022-41080) walked around them by knocking on OWA instead of Autodiscover, and Play ransomware walked in. Mitigations aren't fixes.
One email, every weekday morning.
You're in. Check your inbox.