VMware vCenter Server 6

Tenable plugin 183957 maps to CVE-2023-34048, an out-of-bounds write in vCenter Server's DCERPC implementation that can lead to unauthenticated remote code execution. Affected ranges are vCenter 6.5 < 6.5 U3v, 6.7 < 6.7 U3t, 7.0 < 7.0 U3o, and 8.0 < 8.0 U1d; Broadcom also lists 8.0 U2 as fixed and shipped async fixes for VCF 4.x/5.x.

The vendor's CRITICAL 9.8 is technically fair, but operationally incomplete. This is not a generic internet-grade HTTPS bug against every exposed vCenter admin page; exploitation depends on network reachability to the vulnerable DCERPC management path, which is often restricted to management networks or blocked in managed offerings. That reachability friction downgrades it from blanket CRITICAL to HIGH, but only barely, because VMware confirmed in-the-wild exploitation and a compromised vCenter is a control-plane compromise with ugly blast radius.

Why this verdict

• Downshift for reachability: vendor 9.8 assumes any network path is enough, but real exploitation depends on access to the vulnerable DCERPC management path, which many enterprises keep off untrusted networks.
• Upweight for blast radius: vCenter is not just another server; it is the management plane for ESXi and often the shortest route to hypervisor and guest-level follow-on abuse.
• Upweight for reality, not theory: VMware confirmed exploitation in the wild, Mandiant tied it to UNC3886, and CISA KEV status removes any argument that this is merely laboratory risk.

Why not higher?

I am not calling this CRITICAL across the board because the reachable population is meaningfully narrower than the CVSS headline implies. If your segmentation is decent, this is often a post-initial-access or admin-network opportunity, not a universal internet-facing emergency on every vCenter asset.

Why not lower?

I am not pushing this to MEDIUM because the attack is pre-auth, the impact is RCE on vCenter, and the victim asset is a crown-jewel control plane. KEV listing and confirmed real-world exploitation keep this out of backlog territory.

1. Block untrusted paths to vCenter management ports — Immediately, within hours, restrict the vulnerable vCenter management-plane ports to dedicated admin jump hosts and approved management networks only. Because this CVE is KEV-listed and actively exploited, do not wait for the normal HIGH timeline; use ACLs, NGFW policy, and microsegmentation as an emergency containment move.
2. Enforce jump-host-only administration — Immediately, within hours, force vCenter access through hardened bastions with logging instead of broad workstation reachability. This directly attacks the biggest prerequisite in the exploit chain: attacker network position.
3. Hunt for vmdird crash artifacts — Immediately, within hours, review /var/log/vMonCoredumper.log, appliance service crash records, and unexpected binaries or outbound connections from the vCenter appliance. Mandiant linked vmdird crashes closely to exploit activity, so this is one of the few concrete post-exploit breadcrumbs defenders actually get.
4. Review east-west access to ESXi and guest operations — Within 30 days if not already covered by the emergency response, verify that a compromised vCenter cannot trivially fan out to every management tier without additional controls. This matters because the blast radius, not just the initial exploit, is what keeps the severity high.

Run this on the target vCenter Server Appliance over SSH, after dropping from the appliance shell into bash if needed. Invoke it as sudo bash ./check-cve-2023-34048.sh; root is preferred because some environments restrict access to vpxd -v, but read-only shell access is usually enough.

#!/usr/bin/env bash
# check-cve-2023-34048.sh
# Detect likely exposure to CVE-2023-34048 on VMware vCenter Server Appliance.
# Outputs one of: VULNERABLE / PATCHED / UNKNOWN
# Exit codes: 0=PATCHED, 1=VULNERABLE, 2=UNKNOWN

set -u

get_version_output() {
  if command -v vpxd >/dev/null 2>&1; then
    vpxd -v 2>/dev/null && return 0
  fi
  if [ -x /usr/sbin/vpxd ]; then
    /usr/sbin/vpxd -v 2>/dev/null && return 0
  fi
  if [ -x /usr/lib/vmware-vpx/vpxd ]; then
    /usr/lib/vmware-vpx/vpxd -v 2>/dev/null && return 0
  fi
  return 1
}

OUT="$(get_version_output)" || {
  echo "UNKNOWN - unable to execute vpxd -v"
  exit 2
}

# Expected examples vary, but usually contain version and build tokens.
# Example: VMware VirtualCenter 7.0.3 build-22357613
VERSION="$(printf '%s\n' "$OUT" | grep -Eo '[0-9]+\.[0-9]+\.[0-9]+' | head -n1)"
BUILD="$(printf '%s\n' "$OUT" | grep -Eo 'build[- ]?[0-9]+' | grep -Eo '[0-9]+' | head -n1)"

if [ -z "${VERSION:-}" ] || [ -z "${BUILD:-}" ]; then
  echo "UNKNOWN - could not parse version/build from: $OUT"
  exit 2
fi

major_minor="$(printf '%s' "$VERSION" | awk -F. '{print $1 "." $2}')"
status="UNKNOWN"
reason="unsupported or unrecognized version family"

case "$major_minor" in
  "6.5")
    # Fixed in 6.5 U3v, build 22499743
    if [ "$BUILD" -ge 22499743 ] 2>/dev/null; then
      status="PATCHED"
      reason="6.5 build >= 22499743 (6.5 U3v)"
    else
      status="VULNERABLE"
      reason="6.5 build < 22499743 (before 6.5 U3v)"
    fi
    ;;
  "6.7")
    # Fixed in 6.7 U3t, appliance build 22509751
    if [ "$BUILD" -ge 22509751 ] 2>/dev/null; then
      status="PATCHED"
      reason="6.7 build >= 22509751 (6.7 U3t appliance)"
    else
      status="VULNERABLE"
      reason="6.7 build < 22509751 (before 6.7 U3t)"
    fi
    ;;
  "7.0")
    # Fixed in 7.0 U3o, build 22357613
    if [ "$BUILD" -ge 22357613 ] 2>/dev/null; then
      status="PATCHED"
      reason="7.0 build >= 22357613 (7.0 U3o)"
    else
      status="VULNERABLE"
      reason="7.0 build < 22357613 (before 7.0 U3o)"
    fi
    ;;
  "8.0")
    # Fixed in 8.0 U1d, build 22368047; 8.0 U2 is also fixed and newer.
    if [ "$BUILD" -ge 22368047 ] 2>/dev/null; then
      status="PATCHED"
      reason="8.0 build >= 22368047 (8.0 U1d / U2+)"
    else
      status="VULNERABLE"
      reason="8.0 build < 22368047 (before 8.0 U1d)"
    fi
    ;;
  *)
    # Newer families are outside this plugin's scope.
    status="UNKNOWN"
    reason="version family $major_minor not covered by this check"
    ;;
esac

echo "$status - version=$VERSION build=$BUILD ($reason)"
case "$status" in
  PATCHED) exit 0 ;;
  VULNERABLE) exit 1 ;;
  *) exit 2 ;;
esac

Sources

1. Tenable Nessus Plugin 183957
2. Broadcom / VMware VMSA-2023-0023.1
3. NVD CVE-2023-34048
4. CISA KEV Alert for CVE-2023-34048
5. Mandiant / Google Cloud: UNC3886 exploiting CVE-2023-34048 since late 2021
6. Google Cloud VMware Engine security bulletins
7. Censys exposure analysis for CVE-2023-34048
8. vCenter release and build number history