CVE-2021-22005: VMware vCenter arbitrary file upload to RCE, exploited in the wild
The short version: VMware vCenter Server has an arbitrary file upload flaw (CVE-2021-22005) in its Analytics (CEIP) service that lets an attacker with network access to port 443 upload a crafted file and execute code on the appliance — regardless of vCenter's configuration. VMware confirmed in-the-wild exploitation within days, and it's in CISA's KEV catalog. If your vCenter is reachable and unpatched, this is patch-and-verify. Steady hands — but move.
At a glance
| Fact | Detail |
|---|---|
| Our severity take | Critical — in practice and on paper |
| CVSS v3.1 (NVD) | 9.8 — Critical · AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H |
| EPSS | ~100% · 99.99th percentile (2026-07-17) |
| In CISA KEV? | Yes — remediation was due 2021-11-17 |
| Known exploited? | Yes — VMware confirmed in-the-wild exploitation; CISA notes known ransomware use |
| Vulnerability type | CWE-22 path traversal / arbitrary file upload → remote code execution |
| Requires authenticated session? | No — pre-authentication |
| Affected | vCenter Server 6.7 and 7.0 (6.5 not affected); Cloud Foundation 3.x and 4.x |
| Fixed in | vCenter Server 7.0 U2c · 6.7 U3o (and matching Cloud Foundation releases) |
What you need to know
CVE-2021-22005 is an arbitrary file upload in the vCenter Analytics service (part of the Customer Experience Improvement Program telemetry). An attacker with network access to port 443 uploads a specially crafted file and executes code on the vCenter Server Appliance. VMware was explicit that exploitation works regardless of the configuration settings of vCenter — you can't configure your way out of it.
Why it's about as bad as external exposure gets:
- vCenter runs your virtual estate. Code execution on it reaches the ESXi hosts and VMs it manages.
- Configuration doesn't save you. Turning off telemetry (CEIP) is not an effective mitigation; only the documented workaround or the patch is.
- It was confirmed exploited fast. VMware confirmed in-the-wild activity within days of the advisory, a Metasploit module followed, and CISA notes known ransomware use.
How serious we see it
Critical — in practice and on paper.
Unauthenticated, network-reachable code execution on the platform that runs your virtual infrastructure, confirmed exploited and in KEV, is top-of-queue. The 9.8 fits. The bounded, reassuring part is that it's specific and fixable: particular vCenter and Cloud Foundation builds, published fixes, and a documented interim workaround (per VMware's KB — note that disabling CEIP is not sufficient). The catch is the same as any confirmed in-the-wild flaw — patched and clean are separate questions, so hunt if you were exposed.
Recommendations
Straight from VMware's advisory (VMSA-2021-0020) and CISA:
- Patch now. Upgrade to vCenter Server 7.0 U2c / 6.7 U3o or later.
- If you can't patch immediately, apply VMware's workaround. Follow the KB steps in the advisory — disabling CEIP alone does not prevent exploitation.
- Hunt for prior use. Review logs for unexpected uploads to the Analytics service and signs of code execution on the host.
- If you find indicators, respond fully. Rebuild where warranted and rotate credentials, keys, and certificates.
- Get vCenter off the public internet. Restrict management access to trusted networks.
How BreachRisk sees it
BreachRisk discovers internet-facing vCenter Server instances from little more than your domain, fingerprints the product and version, and flags exposure tied to CVE-2021-22005 — raised to the top because it's in KEV and tied to ransomware. Because verifying this flaw would mean uploading a file to your server, BreachRisk does not attempt exploitation: it detects and flags the exposed, affected version rather than writing anything to the appliance, so the assessment never changes your system's state.
That outside-in, continuous view is the point: when a vCenter RCE breaks, the exposed appliance is already mapped, so you go straight to patch-and-verify.