CVE-2026-34567: Unauthenticated vCenter RCE via SSRF-to-JMX chain

CVE-2026-34567 is a pre-authentication SSRF in vCenter's vRealize Operations plugin servlet (/ui/vropspluginui/rest/services/updateova) that reaches the internal ActiveMQ JMX broker listening on 127.0.0.1:61616. The broker accepts serialized Java objects; a crafted ActiveMQ message triggers deserialization RCE as the vpxd service account — the account that runs the entire vCenter management plane. The exploit is unauthenticated, network-reachable from anywhere vCenter's HTTPS port (443) is exposed, and chains two bugs the vendor had separately tracked for years.

Why this is a ransomware-grade exposure

vCenter is the control plane for every ESXi hypervisor in the environment. Code execution as vpxd means direct access to the hypervisor API, which in turn means direct access to every VM disk. Ransomware operators have spent two years building tooling around vCenter compromise (ESXiArgs, Royal, Akira families). This CVE is the next link in that chain — a pre-auth RCE against vCenter is the kind of bug that turns a regional outage into a nation-scale event.

The exploit shape:

• Step 1: POST to /ui/vropspluginui/rest/services/updateova with a repoUrl parameter pointing at an attacker-controlled server. Servlet fetches the URL without validation.
• Step 2: Attacker replies with a 302 redirect to tcp://127.0.0.1:61616/. The underlying Apache HttpClient follows the redirect into the JMX broker.
• Step 3: Attacker-supplied body contains a serialized ActiveMQ ConsumerControl with a gadget chain. Broker deserializes. RCE as vpxd.

Pre-auth RCE on a ransomware operator's favorite target is a Tuesday-evening patch. No maintenance window argument applies here.

Who is exposed

• Every vCenter on 7.0 through 8.0 U3b. The vulnerable servlet ships enabled by default.
• Internet-facing vCenter (Shodan shows ~2,100 instances with /ui/ reachable). Patch today, not Friday.
• Internal-only vCenter — still exposed to any attacker with a foothold on any VLAN that can reach port 443. Treat as post-compromise amplifier, still urgent.
• vCenter running vROps plugin — the plugin is installed by default; even if you don't use vROps, the plugin servlet is still active.

Mitigation

Apply the patch. Fixed versions:

• vCenter 8.0 U3c (build 23765000 or later).
• vCenter 7.0 U3r (build 23820000 or later).

Between patch-download and maintenance-window, mitigate with:

• Block /ui/vropspluginui/ at the ingress layer — upstream reverse proxy, F5 iRule, or NGINX location block returning 403. This disables the vulnerable servlet without touching vCenter.
• Firewall TCP/61616 on the vCenter host to loopback only (it should be already, but verify — misconfiguration has been observed in customer deployments).
• Run the VMware CVE-2026-34567-check.sh — included in the artifact folder — to confirm vROps plugin version and flag vulnerable installs.

The broader pattern

vCenter CVEs in the past three years: CVE-2021-21972 (vROps SSRF→RCE), CVE-2023-34048 (DCE/RPC OOB), CVE-2024-37079, CVE-2024-38812, now CVE-2026-34567. Each one uses the same shape — internet-reachable management plane, Java deserialization chain, unauth or near-unauth RCE. If you're still running vCenter with HTTPS exposed to the internet, you have made a strategic bet that the next one of these will not be zero-day at disclosure. That bet has failed several times.