VMware vCenter Server 7

CVE-2025-41241 is a denial-of-service flaw in VMware vCenter's guest OS customisation API path. Broadcom says a malicious actor must already be authenticated through vCenter and have permission to perform guest OS customisation API calls to trigger it. Affected ranges are vCenter 7.0 before 7.0 U3v and 8.0 before 8.0 U3g; Broadcom also maps related exposure into Cloud Foundation 4.5.x/5.x and certain Telco Cloud products through their bundled vCenter component.

Broadcom/Tenable calling this MEDIUM is technically fair, but for a 10,000-host enterprise I'd still downgrade it to LOW. The decisive friction is not the crash itself; it's the attacker position required to reach it: authenticated access plus a privileged, specialized API permission set inside vCenter. That's already post-initial-access and usually limited to VMware admins or tightly scoped automation accounts.

Why this verdict

• Downward pressure: requires authenticated remote access — this is not a pre-auth edge bug; it assumes the attacker is already inside your management plane.
• Downward pressure: requires specific high privileges — Broadcom scored it PR:H, and the vulnerable path is tied to guest OS customisation APIs that many users never touch.
• Downward pressure: narrow real-world blast radius — the impact is vCenter availability, not code execution, not credential theft, and not direct host compromise.
• Slight upward pressure: vCenter is operationally central — even a DoS against the control plane can jam automation, provisioning, and admin recovery during an incident.
• Downward pressure: no public exploitation traction — no KEV listing, no public PoC of note, and very low EPSS all argue against emergency treatment.

Why not higher?

To score this MEDIUM or HIGH in a defender-focused queue, I'd need either pre-auth reachability, broadly granted permissions, or active exploitation evidence. We have none of those here. The exploit chain starts too far downstream in the kill chain to justify burning emergency patch bandwidth for most shops.

Why not lower?

I would not mark it IGNORE because vCenter is a crown-jewel management system and service disruption there has outsized operational impact. Also, some enterprises give powerful rights to CI/CD, backup, or provisioning accounts; if one of those is compromised, this nuisance becomes a very real outage lever.

1. Strip guest customisation rights from non-admin accounts — Review vCenter roles, folders, and automation service accounts and remove guest OS customisation API permissions wherever they are not strictly needed. For a LOW verdict there is no mitigation SLA; treat this as backlog hygiene and complete it in the next normal IAM/VMware permission review cycle.
2. Constrain vCenter to management-only paths — Keep vCenter reachable only from admin workstations, jump hosts, VPN, or management VLANs so credential theft elsewhere in the estate does not immediately convert into API access. For a LOW verdict there is no mitigation SLA; enforce this through your normal segmentation program rather than an emergency network change.
3. Monitor guest customisation API usage — Alert on unusual guest customisation tasks, spikes in API calls from automation accounts, and vpxd/vmon instability so you can spot abuse before it becomes an outage. For a LOW verdict there is no mitigation SLA; add it during your next vCenter logging and detection tuning pass.

Run this on the vCenter Server Appliance itself over SSH or the console as root or another account that can execute vpxd -v. Save it as check-cve-2025-41241.sh, then run bash check-cve-2025-41241.sh. It checks local vCenter version/build and prints VULNERABLE, PATCHED, or UNKNOWN.

#!/usr/bin/env bash
# check-cve-2025-41241.sh
# Verifies whether a VMware vCenter Server Appliance is below the fixed builds
# for CVE-2025-41241.
# Fixed thresholds:
#   7.0 U3v  -> build 24730281
#   8.0 U3g  -> build 24853646
# Exit codes:
#   0 = PATCHED / UNAFFECTED
#   1 = VULNERABLE
#   2 = UNKNOWN / could not determine

set -u

FIX_7_BUILD=24730281
FIX_8_BUILD=24853646

get_vpxd_output() {
  if command -v vpxd >/dev/null 2>&1; then
    vpxd -v 2>/dev/null
    return 0
  fi
  return 1
}

OUT="$(get_vpxd_output)"
if [ -z "$OUT" ]; then
  echo "UNKNOWN - unable to run 'vpxd -v' on this host"
  exit 2
fi

# Typical output examples include a version and a 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 - parsed output was insufficient: $OUT"
  exit 2
fi

MAJOR="$(printf '%s' "$VERSION" | cut -d. -f1)"
MINOR="$(printf '%s' "$VERSION" | cut -d. -f2)"
PATCH="$(printf '%s' "$VERSION" | cut -d. -f3)"

# vCenter 9.x is explicitly unaffected per Broadcom response matrix.
if [ "$MAJOR" -ge 9 ] 2>/dev/null; then
  echo "PATCHED - version $VERSION build $BUILD (9.x is listed as unaffected)"
  exit 0
fi

# Affected supported lines in advisory: 7.0 and 8.0
if [ "$MAJOR" = "7" ] && [ "$MINOR" = "0" ]; then
  if [ "$BUILD" -ge "$FIX_7_BUILD" ]; then
    echo "PATCHED - version $VERSION build $BUILD (>= 7.0 U3v build $FIX_7_BUILD)"
    exit 0
  else
    echo "VULNERABLE - version $VERSION build $BUILD (< 7.0 U3v build $FIX_7_BUILD)"
    exit 1
  fi
fi

if [ "$MAJOR" = "8" ] && [ "$MINOR" = "0" ]; then
  if [ "$BUILD" -ge "$FIX_8_BUILD" ]; then
    echo "PATCHED - version $VERSION build $BUILD (>= 8.0 U3g build $FIX_8_BUILD)"
    exit 0
  else
    echo "VULNERABLE - version $VERSION build $BUILD (< 8.0 U3g build $FIX_8_BUILD)"
    exit 1
  fi
fi

echo "UNKNOWN - version $VERSION build $BUILD is outside the advisory's 7.0/8.0 scope"
exit 2

Sources

1. Broadcom VMSA-2025-0014 advisory
2. NVD CVE-2025-41241
3. OpenCVE record for CVE-2025-41241
4. Tenable CVE page mapping plugin 245963
5. Vulners record with EPSS mirror
6. CISA Known Exploited Vulnerabilities catalog
7. Virten vCenter release and build number history
8. Censys prior vCenter exposure analysis