VMware vCenter Server 7

This maps to CVE-2023-34056, a partial information disclosure flaw in VMware vCenter Server. Affected ranges are 7.0 before 7.0U3o and 8.0 before 8.0U2; Broadcom also ties impacted VMware Cloud Foundation 4.x/5.x deployments to the vulnerable embedded vCenter component. The vendor description is narrow on purpose: an attacker needs non-administrative vCenter privileges first, then can access data they should not be able to read.

Vendor MEDIUM / 4.3 is technically fair, but for enterprise patch prioritization it lands lower. The decisive friction is the attacker position: this is post-auth against a heavily restricted management plane, and the published impact is partial confidentiality only with no integrity or availability loss. On a 10,000-host patch board, that is not the same animal as the unauthenticated vCenter bugs that have historically driven mass exploitation.

Why this verdict

• Downshift for attacker position: the vendor 4.3 baseline assumes only PR:L, but in the real world that means the attacker already has a vCenter account or token, which usually implies prior compromise, insider access, or delegated admin-plane reach.
• Downshift for reachable population: even though some vCenter instances are internet-exposed, most enterprises keep vCenter behind VPN, jump hosts, or management enclaves. Requiring both network reachability and valid low-priv authentication compounds the friction.
• Downshift for blast radius: the published impact is partial information disclosure only. No direct code execution, no privilege escalation, and no service disruption are attributed to this CVE.

Why not higher?

It is not higher because this is not unauthenticated, not wormable, and not a direct control-plane takeover. The attacker still needs a separate path to get useful vCenter access before the bug does anything, and the CVE by itself does not hand them admin or execution.

Why not lower?

It is not lower because vCenter is a crown-jewel management system, so even a limited information leak can improve attacker recon materially. If an environment has broad read-only vCenter roles, shared operations accounts, or internet-exposed management surfaces, the practical risk rises above pure backlog noise.

1. Collapse low-priv vCenter access — Review and reduce read-only, audit, and delegated operator roles so fewer identities can reach the vulnerable surface. For a LOW verdict there is no formal mitigation SLA; treat this as backlog hygiene and complete during the next access-review cycle.
2. Keep vCenter off the internet — Force access through VPN, bastions, or admin enclaves and block direct exposure of 443 and 5480 from untrusted networks. This does not patch the bug, but it removes the easiest path to satisfying the network prerequisite; for LOW, do it as normal hygiene rather than emergency work.
3. Put MFA and PAM in front of vCenter — Since the attacker must authenticate first, strong auth and session brokering materially reduce exploitability. Apply to all human vCenter access and privileged automation accounts; for LOW, schedule in routine hardening if not already in place.
4. Alert on odd non-admin reads — Baseline which users and tools normally query inventory and configuration data, then alert when low-priv identities enumerate unusually broad objects or log in from unusual hosts. This is your best chance to catch abuse because exploit-specific signatures are weak.

Run this on the target vCenter Server Appliance over SSH as root or another account allowed to execute vpxd -v. Example: ssh [email protected] 'bash -s' < check_cve_2023_34056.sh. It needs only local shell access and no network reachability beyond the SSH session.

#!/usr/bin/env bash
# check_cve_2023_34056.sh
# Determine whether a VMware vCenter Server Appliance is vulnerable to CVE-2023-34056
# Affected: 7.0 < 7.0U3o ; 8.0 < 8.0U2
# Output: VULNERABLE / PATCHED / UNKNOWN
# Exit codes: 0=PATCHED, 1=VULNERABLE, 2=UNKNOWN

set -u

fail_unknown() {
  echo "UNKNOWN: $1"
  exit 2
}

# Broadcom KB 380386 documents 'vpxd -v' as a supported way to check vCenter version.
if ! command -v vpxd >/dev/null 2>&1; then
  fail_unknown "vpxd command not found; are you on a vCenter Server Appliance?"
fi

raw="$(vpxd -v 2>/dev/null | tr '\n' ' ')"
[ -n "$raw" ] || fail_unknown "vpxd -v returned no data"

# Try to extract a version string like 7.0.3.01700 or 8.0.2.00000
ver="$(printf '%s' "$raw" | grep -Eo '[0-9]+\.[0-9]+\.[0-9]+\.[0-9]+' | head -n1)"
[ -n "$ver" ] || fail_unknown "could not parse version from: $raw"

IFS='.' read -r major minor patch build <<< "$ver"
for n in "$major" "$minor" "$patch" "$build"; do
  [[ "$n" =~ ^[0-9]+$ ]] || fail_unknown "non-numeric version component in $ver"
done

# Normalize any leading zeros safely
major=$((10#$major))
minor=$((10#$minor))
patch=$((10#$patch))
build=$((10#$build))

# Compare a.b.c.d tuples
ver_ge() {
  local a1=$1 b1=$2 c1=$3 d1=$4
  local a2=$5 b2=$6 c2=$7 d2=$8

  if (( a1 > a2 )); then return 0; fi
  if (( a1 < a2 )); then return 1; fi
  if (( b1 > b2 )); then return 0; fi
  if (( b1 < b2 )); then return 1; fi
  if (( c1 > c2 )); then return 0; fi
  if (( c1 < c2 )); then return 1; fi
  if (( d1 >= d2 )); then return 0; fi
  return 1
}

# Fixed minimums for this CVE
# 7.0U3o  => 7.0.3.01700
# 8.0U2   => 8.0.2.00000

if (( major == 7 && minor == 0 )); then
  if ver_ge "$major" "$minor" "$patch" "$build" 7 0 3 1700; then
    echo "PATCHED: detected vCenter version $ver (>= 7.0.3.01700 / 7.0U3o)"
    exit 0
  else
    echo "VULNERABLE: detected vCenter version $ver (< 7.0.3.01700 / 7.0U3o)"
    exit 1
  fi
elif (( major == 8 && minor == 0 )); then
  if ver_ge "$major" "$minor" "$patch" "$build" 8 0 2 0; then
    echo "PATCHED: detected vCenter version $ver (>= 8.0.2.00000 / 8.0U2)"
    exit 0
  else
    echo "VULNERABLE: detected vCenter version $ver (< 8.0.2.00000 / 8.0U2)"
    exit 1
  fi
else
  fail_unknown "version $ver is outside the 7.0/8.0 ranges covered by this check"
fi

Sources

1. Tenable plugin 183958
2. Broadcom / VMware VMSA-2023-0023.1
3. NVD CVE-2023-34056
4. Broadcom KB 326316 - vCenter versions and build numbers
5. Broadcom KB 380386 - checking version with vpxd -v
6. CISA Vulnerability Summary for the Week of October 23, 2023
7. Censys - VMware vCenter exposure analysis
8. CVEDetails EPSS and metadata for CVE-2023-34056