VMware vCenter Server 8

CVE-2025-41228 is a reflected XSS in VMware vCenter Server 8.0 caused by improper input validation on certain login-page or UI URL paths. For the vCenter side, the affected train is 8.0 prior to 8.0 U3e; Broadcom's fixed build is 8.0 U3e / 8.0.3.00500 / build 24674346. This is not the scary authenticated command-exec in the same advisory; this one needs a browser to render attacker-controlled input and turns into cookie theft, phishing, or admin-session abuse.

Reality is lower than the scanner label. Broadcom scored this 4.3 / MEDIUM, and that is closer to the truth than Tenable's plugin page calling it high: the chain requires network reachability + user interaction + usually a privileged vSphere admin context, and most enterprises keep vCenter on a management network instead of on the public internet. High-value target, yes; broad unauthenticated takeover path, no.

Why this verdict

• Tenable is overcalling it: Broadcom's own rating for CVE-2025-41228 is MEDIUM 4.3, while the Tenable plugin page marks the check high even though the plugin is just version matching.
• User interaction is the biggest brake: the attacker needs a vSphere admin to open a crafted URL, which implies phishing or an already-compromised admin browser/workstation rather than clean unauthenticated exploitation.
• Exposure is usually narrow: vCenter normally sits on an internal management plane or VPN. Requiring both network reachability to vCenter and a privileged victim compounds downward pressure hard.
• Impact is browser-context first, infrastructure second: the dangerous part is session abuse after the click, not direct server-side code execution.
• Affected population is narrower than the plugin title suggests: Broadcom's matrix shows vCenter Server 8.0 affected for this CVE; it does not flag vCenter 7.0 for CVE-2025-41228.

Why not higher?

There is no evidence here of unauthenticated server-side code execution, no KEV listing, and no active exploitation signal in the retrieved sources. The chain needs a reachable vCenter plus a successful lure against a high-value but small admin audience, which is materially less scalable than the vCenter bugs that deserve HIGH or CRITICAL treatment.

Why not lower?

It still touches vCenter, which is a crown-jewel control plane. If an attacker lands script execution in a real admin's browser session, the follow-on consequences can be ugly, so this is not something to ignore outright.

1. Keep vCenter off the internet — Restrict vCenter UI reachability to management networks, jump hosts, or VPN-only access. For a LOW verdict there is no SLA under noisgate; treat this as backlog hygiene, but if any instance is internet-facing, fix the exposure outside normal backlog handling because that single decision removes the biggest friction in the attack chain.
2. Constrain who can browse to vCenter — Use hardened admin workstations, separate admin browsing from general web/email activity, and keep vCenter administration off day-to-day endpoints. For LOW, there is no formal mitigation SLA; roll this into your standing admin-tier hardening program.
3. Hunt for suspicious vCenter URLs in mail and proxy logs — Search for vCenter links containing odd query strings or unusual /folder requests sent to admin staff. For LOW, there is no mitigation SLA, but this is cheap validation that can confirm whether anyone is trying to operationalize the bug against your admins.
4. Tighten vCenter RBAC — Reduce the number of users holding top-level vCenter rights so a successful browser-context hijack lands in fewer high-impact sessions. With a LOW verdict, schedule this as normal access-governance work rather than emergency change.

Run this on the vCenter Server Appliance itself over SSH as a user that can execute vpxd -v (root is simplest). Example: ssh [email protected] 'bash -s' < check_cve_2025_41228.sh. It needs only local shell access; no downtime and no config changes.

#!/usr/bin/env bash
# check_cve_2025_41228.sh
# Detects whether VMware vCenter Server is vulnerable to CVE-2025-41228
# Scope: vCenter Server 8.0 builds prior to 8.0 U3e / build 24674346
# Output: VULNERABLE / PATCHED / UNKNOWN
# Exit codes: 0=PATCHED, 1=VULNERABLE, 2=UNKNOWN

set -u

FIXED_BUILD=24674346

have_cmd() {
  command -v "$1" >/dev/null 2>&1
}

get_vpxd_output() {
  if have_cmd vpxd; 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_vpxd_output || true)"

if [ -z "$OUT" ]; then
  echo "UNKNOWN: could not execute 'vpxd -v'; this host may not be a vCenter appliance or the path is non-standard"
  exit 2
fi

# Typical output examples vary, so extract the first version-like token and build number.
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: unable to parse version/build from output: $OUT"
  exit 2
fi

case "$VERSION" in
  8.0* )
    if [ "$BUILD" -lt "$FIXED_BUILD" ]; then
      echo "VULNERABLE: vCenter $VERSION build-$BUILD is older than fixed build-$FIXED_BUILD (8.0 U3e)"
      exit 1
    else
      echo "PATCHED: vCenter $VERSION build-$BUILD is at or newer than fixed build-$FIXED_BUILD"
      exit 0
    fi
    ;;
  7.0*|9.* )
    echo "PATCHED: this script targets the vCenter 8.0 branch for CVE-2025-41228; detected $VERSION build-$BUILD"
    exit 0
    ;;
  * )
    echo "UNKNOWN: unrecognized vCenter version '$VERSION' build-$BUILD"
    exit 2
    ;;
esac

Sources

1. Broadcom VMSA-2025-0010 advisory
2. NVD CVE-2025-41228
3. Tenable Nessus plugin 237248
4. Broadcom vCenter build numbers
5. Exploit-DB EDB-52406
6. Tenable CVE page with EPSS snapshot
7. CVEDetails EPSS and PoC snapshot
8. Censys historical vCenter exposure context