CVE-2026-22719: VMware Aria Operations Command Injection Now Actively Exploited

I woke up yesterday morning to a CISA alert that made my stomach drop. Another VMware flaw, already being weaponized in the wild— CVE-2026-22719. If you're running VMware Aria Operations, formerly known as vRealize Operations, you need to stop what you're doing and patch this. Like, actually do it now, not after your standup.

Here's the brutal truth: this isn't a hypothetical risk anymore. CISA added it to their Known Exploited Vulnerabilities catalog on March 3rd, and federal agencies have until March 24th to patch. That means real attackers are already using it against real targets. Your infrastructure might be one of them.

What's at Stake

VMware Aria Operations isn't some niche tool buried in the depths of IT. It's the monitoring heartbeat for countless enterprise environments—tracking server performance, cloud health, network metrics across vSphere, Kubernetes, and hybrid cloud setups. When you compromise the monitoring platform, you get a god-tier view of the entire infrastructure. We're talking about privileged access to the very system designed to watch everything.

I've seen shops running Aria Operations without proper segmentation, exposing management interfaces directly to the internet because "it's behind a VPN" or MFA supposedly protects it. Spoiler alert: when you have an unauthenticated command injection flaw, MFA doesn't matter. The attacker never authenticates.

CVE-2026-22719 earns a CVSS score of 8.1—high severity for good reason. It's a command injection vulnerability that allows unauthenticated attackers to execute arbitrary commands. Let that sink in: no authentication required. You don't need to compromise a user account first. You don't need valid credentials. You just need network access to the vulnerable appliance during a specific condition.

The Vulnerability Explained

The command injection flaw lives in the migration functionality—specifically during support-assisted product migration. When you're migrating Aria Operations instances, certain components exposed on the appliance don't properly sanitize input, allowing an attacker to inject malicious commands that execute with system-level privileges.

Here's the kicker: the vulnerability stems from a sudoers configuration problem. The vmware-casa-workflow.sh script could be executed as root without a password, and the migration service script at /usr/lib/vmware-casa/migration/vmware-casa-migration-service.sh exposed the attack surface. When an attacker can chain these together, they achieve unauthenticated remote code execution.

This isn't just about popping a shell. Once an attacker has root on the appliance, they can:

• Dump credentials stored in the credential vault
• Pivot to vCenter, which Aria Ops connects to for monitoring
• Scan internal networks from a trusted position
• Modify monitoring rules to hide their activity
• Deploy persistence tools that blend in with legitimate operations

The exploitation window is specific—it requires the system to be in a migration state. But here's what attackers know: enterprise migrations aren't rare events. Mergers, acquisitions, cloud migrations, infrastructure overhauls—these happen all the time. Attackers are opportunistic. They watch for migration activities, or worse, they can trigger migration workflows through other means. And if your org has Aria Ops permanently in a migration-ready state (yes, I've seen this), you're always exposed.

Are You Affected?

Check your versions now. The vulnerability impacts:

• VMware Aria Operations 8.x — Patched in 8.18.6
• VMware Cloud Foundation 9.x.x.x — Patched in 9.0.2.0
• VMware vSphere Foundation 9.x.x.x — Patched in 9.0.2.0

If you're running anything below these patch levels, you're vulnerable. And yes, that includes you—the shop that's "too busy" to upgrade, the team that's "planning a maintenance window" next quarter, the org that pushed migrations to the back burner. Attackers don't care about your maintenance windows.

This advisory also covers CVE-2026-22720 (stored XSS) and CVE-2026-22721 (privilege escalation). The XSS flaw could be chained for initial access, while the privilege escalation gives attackers more paths once they're in. Treat the whole patch bundle as mandatory.

Quick Version Check

# SSH into your Aria Operations appliance
ssh root@<your-aria-ops-appliance>

# Check the version
cat /etc/issue
# or
rpm -qa | grep aria-operations

# For Cloud Foundation or vSphere Foundation, check:
cat /etc/vmware/.buildVersion

If you see anything below 8.18.6 or 9.0.2.0, you've got work to do.

How to Patch

Primary solution: apply the patches from Broadcom's VMSA-2026-0001 advisory. These aren't optional updates—they're security patches that address this command injection along with the other CVEs.

Patch the appliance:

1. Download the patch from Broadcom's customer portal
2. Upload to your Aria Operations cluster
3. Apply through the admin interface or CLI
4. Reboot if required (check the patch notes)
5. Verify the patch applied successfully

# Verify patch version after applying
rpm -qa | grep vmware-aria-operations

# Check build date
ls -la /usr/lib/vmware-aria-ops/

This sounds simple, and it is—if you have a patch management process. If you don't, now's the time to build one. Test in a non-production environment first. Yes, this takes time. No, you can't skip it. Rollbacks are real.

When You Can't Patch Immediately

I get it. Some environments can't just hot-swap appliances. Change windows, production dependencies, the whole enterprise reality. If you're stuck, apply the workaround.

VMware provides a script called aria-ops-rce-workaround.sh that disables the vulnerable migration components. You need to run this as root on every node of your Aria Operations Virtual Appliance:

# Download and run the workaround script
# (Obtain from Broadcom's security bulletin)
chmod +x aria-ops-rce-workaround.sh
sudo ./aria-ops-rce-workaround.sh

# Verify the workaround applied
# The migration service should be disabled
systemctl status vmware-casa-migration

# Check sudoers entry was removed
sudo -l | grep casa

This script removes the migration service file and the problematic sudoers entry:

• Deletes /usr/lib/vmware-casa/migration/vmware-casa-migration-service.sh
• Removes NOPASSWD: /usr/lib/vmware-casa/bin/vmware-casa-workflow.sh from sudoers

It breaks migration functionality until you patch, but it also breaks the attack path. Trade-off accepted when the alternative is owning your infrastructure.

Detecting Compromise

Here's the scary part: Broadcom acknowledges exploitation reports but can't independently confirm them. That means the activity is happening, but there's no clear public playbook for detecting it yet. You need to hunt on your own Aria Operations appliances.

Check for evidence:

# Look for suspicious process execution
ps aux | grep -E "bash|sh|python|perl|nc|ncat" | grep -v aria

# Check system logs for unusual activity
grep -i "migration" /var/log/syslog | tail -100
grep -i "casa" /var/log/secure | tail -100

# Look for unauthorized file modifications
find /usr/lib/vmware-casa -mtime -7 -ls
find /tmp -mtime -1 -ls

# Check network connections during migration windows
netstat -anp | grep -E :443 | grep ESTABLISHED
ss -tunlp | grep casa

# Check for new user accounts
grep -E "^(user|group)" /etc/passwd /etc/shadow /etc/group | tail -20

# Look for SSH keys that shouldn't be there
find /root/.ssh -type f -mtime -7 -ls

Correlate any suspicious activity with migration timeframes. If you see anomalous processes spawning during or immediately after migration workflows, you might have a problem.

Common post-exploitation indicators:

• Unexpected cron jobs or systemd timers
• New SSH authorized_keys files
• Modified monitoring rules or alerts
• Data exfiltration to unexpected IPs
• Lateral movement attempts to vCenter or other infrastructure

If you suspect compromise, treat it like a full incident response:

1. Isolate the appliance from the network
2. Preserve the filesystem and logs
3. Engage your security team
4. Assume credential exposure—rotate affected secrets
5. Assume lateral movement—scan for pivots to other systems
6. Consider rebuilding from scratch if evidence is unclear

Why This Keeps Happening

VMware vulnerabilities have become a ransomware playground. ESXi, vCenter, NSX—every year brings another critical flaw. The pattern is exhausting: disclosure, patch, exploitation, KEV addition. Meanwhile, enterprises struggle to keep up because virtualization infrastructure is foundational-layer software. You can't just "turn it off" while you troubleshoot.

Aria Operations sits in a sweet spot for attackers: highly privileged, often under-secured, and frequently exposed to internal networks that should be segmented. It's a management plane component with access to credentials across the entire stack. When monitoring tools get owned, the damage cascades.

CISA adding this to KEV within days of the original advisory underscores the tempo. Attackers are weaponizing vulnerabilities faster than ever. You no longer have the luxury of a measured patch cycle. The old model—"we'll patch during the next maintenance window"—is dead if that maintenance window is two weeks out.

Actionable Takeaways

• Check your VMware Aria Operations version immediately. If it's below 8.18.6 or 9.0.2.0, you're exposed. Run the version check commands now. Don't finish this article first.

• Patch to the fixed versions now. This isn't a "nice to have" update— it's an emergency fix for actively exploited code execution. Test, then deploy. Don't wait.

• Run the workaround script if you can't patch. aria-ops-rce-workaround.sh disables the attack vector. It breaks migration until you patch, but that's better than RCE. Document the workaround so you can reverse it later.

• Hunt for compromise indicators on your appliances. Unusual processes, suspicious migrations, anomalous network activity during migration windows. Assume you might already be hit.

• Isolate the appliance if you detect compromise. Assume credential theft. Assume lateral movement. This might be painful, but a rebuild is less painful than a full breach.

• Review your Aria Ops network exposure. Should your management interface be accessible from the internal network? Consider segmenting monitoring infrastructure into its own VLAN with strict access controls.

• Audit who has access to Aria Operations. Reduce privileged accounts, enforce MFA everywhere, implement least privilege. The fewer people who can access the console, the smaller the attack surface.

• Build a patch process for foundational infrastructure. When RCE zero-days hit your hypervisor layer, you need a tested response path—not a five-week change approval cycle. Define your emergency patch workflow before the next CVE drops.

• Monitor for future VMware advisories. Subscribe to Broadcom security notifications, follow CISA KEV updates, set up alerts for new VMSA advisories. The pattern won't stop.

VMware Aria Operations is the eyes of your infrastructure. Right now, those eyes are vulnerable to blinding—and worse, to being turned inward against you. Patch your systems, hunt for compromise, and stop assuming your management tools are safe because they're "internal." That illusion died a long time ago.