CVE-2023-34048: VMware vCenter Server out-of-bounds write RCE, actively exploited
The short version: CVE-2023-34048 is an out-of-bounds write in the DCERPC protocol implementation of VMware vCenter Server. An unauthenticated attacker with network access can trigger it to run code on the vCenter appliance — the control plane for your entire virtual estate. It's a 9.8, it's been used in targeted intrusions, and it's in CISA's KEV catalog. Patch-and-verify. Steady hands — but move.
At a glance
| Fact | Detail |
|---|---|
| Our severity take | High — in practice and on paper |
| CVSS v3.1 (NVD) | 9.8 — Critical · CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H |
| EPSS | 99.43% · 99.94th percentile (2026-07-17) |
| In CISA KEV? | Yes — added 2024-01-22, remediation due 2024-02-12 |
| Known exploited? | Yes — used in targeted, real-world intrusions |
| Vulnerability type | CWE-787 out-of-bounds write in DCERPC → remote code execution |
| Requires authenticated session? | No — network access to vCenter is sufficient |
| Affected | vCenter Server 7.0 (before 7.0 U3o) and 8.0 (before 8.0 U2); VMware Cloud Foundation 4.x and 5.x |
| Fixed in | vCenter Server 7.0 U3o · 8.0 U2 (and later); apply the matching Cloud Foundation async patches |
What you need to know
vCenter Server is the single pane of glass that manages your ESXi hosts and virtual machines. CVE-2023-34048 is a memory-corruption flaw — an out-of-bounds write — in vCenter's DCERPC protocol implementation. A crafted network packet writes outside the bounds of a buffer, and that corruption can be driven into code execution on the appliance.
Why it's a top-priority item:
- It's the control plane. Owning vCenter means reaching every host and VM it manages.
- It's unauthenticated over the network. No credentials needed — just reachability. That is why vCenter should never sit on the public internet.
- It has an espionage track record. This flaw was used in targeted intrusions and later added to CISA KEV, with an exceptionally high EPSS reflecting broad exploitation interest.
How serious we see it
High — the 9.8 holds up.
Unauthenticated remote code execution on the appliance that controls your virtualization estate, with confirmed use by real-world intruders, is the definition of top-of-queue. The bounded, reassuring part: it affects specific vCenter builds, the fixes are published, and exposure is quick to determine. The catch is that this bug was used quietly for initial access — so if your vCenter was reachable, patching is necessary but you should also verify you weren't already touched.
Recommendations
Straight from VMware's advisory (VMSA-2023-0023) and CISA:
- Patch now. Upgrade vCenter Server to 7.0 U3o / 8.0 U2 or later, and apply the corresponding Cloud Foundation patches.
- Hunt. Given the espionage use of this flaw, review vCenter and connected hosts for signs of prior compromise, not just current patch level.
- If compromised, respond. Rotate vCenter credentials and secrets, and investigate lateral movement into ESXi and the VMs it manages.
- Harden exposure. Keep vCenter off the internet; restrict management access to trusted networks and enforce MFA.
- Confirm your exposure first. Verify whether you run an affected vCenter build at all.
How BreachRisk sees it
BreachRisk starts from the outside, the way an attacker does. From little more than your domain it discovers internet-facing VMware management surfaces, fingerprints the vCenter product and version, and flags exposure tied to KEV-listed, actively exploited vulnerabilities like this one — pushed to the top of your results because of how it actually gets used. We detect and prioritize the exposed, affected appliance; we don't exploit the memory-corruption bug.
The whole point of a continuous, attacker's-eye view is flaws like this: a vCenter that should be internal but is reachable from the internet is already on your radar, so you can move straight to patch-and-verify.