VMware vCenter Server 7

Tenable plugin 237247 maps to CVE-2025-41225, an authenticated command-execution flaw in VMware vCenter Server. Affected ranges are 7.0.x before 7.0 U3v and 8.0.x before 8.0 U3e; Broadcom also extends impact to VMware Cloud Foundation 5.x/4.5.x and several Telco Cloud bundles carrying the same vCenter component. The bug lets a user who can create or modify alarms and use the Run Script action cause command execution on the vCenter host itself.

The vendor's HIGH/8.8 score captures the *impact* correctly but overstates the *reach* for most enterprises. This is not an unauthenticated edge bug and not even a generic low-privilege user bug; it requires a post-auth, role-constrained position inside the virtualization management plane. In real fleets, that sharply shrinks the exposed population, so this lands as a MEDIUM operational priority unless you know those privileges are broadly delegated or already suspect vCenter admin credential theft.

Why this verdict

• Requires authenticated remote access first: this is not unauthenticated edge exposure; the attacker must already be inside the vCenter trust boundary.
• Requires a specific privileged role: create/modify alarms plus script-action capability is a much smaller population than 'any vCenter user,' which pushes the vendor's impact-heavy score down.
• vCenter compromise is still consequential: if exploited, the blast radius can be large because vCenter is the virtualization control plane, so this stays above LOW.

Why not higher?

There is no evidence here of mass-reachable exploitation conditions like unauthenticated RCE, broad default exposure, or KEV-listed abuse. Every prerequisite in the chain compounds downward: authenticated access, then specific RBAC, then successful alarm manipulation, then execution and pivot.

Why not lower?

Once the preconditions are met, the payoff is not minor. Command execution on vCenter can expose a management-plane crown jewel, including secrets, automation trust, and administrative reach into clusters and hosts, so treating it as mere backlog hygiene would understate the impact.

1. Trim alarm-script privileges — Review vCenter roles and remove create/modify alarms and script-action capability from anyone who does not truly need it. For a MEDIUM finding there is no mitigation SLA — go straight to the 365-day remediation window, but this is the single best hardening move if patching is delayed.
2. Alert on alarm creation and changes — Send vCenter events for alarm creation, modification, and trigger actions into your SIEM, and specifically flag the use of Run Script. There is no mitigation SLA for MEDIUM, so deploy this through normal detection engineering, but do not let it slip past the 365-day patch window.
3. Isolate the management plane — Keep vCenter reachable only from admin jump hosts or management enclaves, not broad user networks and definitely not the open internet. This does not remove the bug, but it constrains who can reach the authenticated entry point while you patch inside the remediation window.
4. Put vCenter admins behind PAM — Enforce MFA, session recording, and checkout controls for vCenter administration so stolen standing credentials are harder to use. That helps most at step 1 of the attack path, where real-world abuse would begin.

Run this on the target vCenter Server Appliance, not from your scanner. Invoke it as sudo bash check_cve_2025_41225.sh; root or an account that can execute vpxd -v and read basic system files is recommended. The script checks the installed vCenter build and prints VULNERABLE, PATCHED, or UNKNOWN.

#!/usr/bin/env bash
# check_cve_2025_41225.sh
# Detects likely exposure to CVE-2025-41225 on VMware vCenter Server Appliance.
# Exit codes: 0=PATCHED, 1=VULNERABLE, 2=UNKNOWN

set -u

VC7_FIXED_BUILD=24730281
VC8_FIXED_BUILD=24674346

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

extract_build() {
  local src="$1"
  echo "$src" | grep -Eo 'build-?[[:space:]]*[0-9]+' | grep -Eo '[0-9]+' | head -n1
}

extract_version() {
  local src="$1"
  echo "$src" | grep -Eo '[0-9]+\.[0-9]+\.[0-9]+(\.[0-9]+)?' | head -n1
}

RAW=""
if have_cmd vpxd; then
  RAW="$(vpxd -v 2>/dev/null || true)"
fi

if [ -z "$RAW" ] && [ -r /etc/vmware/.buildInfo ]; then
  RAW="$(cat /etc/vmware/.buildInfo 2>/dev/null || true)"
fi

if [ -z "$RAW" ]; then
  echo "UNKNOWN: could not obtain vCenter version/build from vpxd or /etc/vmware/.buildInfo"
  exit 2
fi

BUILD="$(extract_build "$RAW")"
VERSION="$(extract_version "$RAW")"

if [ -z "$VERSION" ]; then
  echo "UNKNOWN: could not parse version from: $RAW"
  exit 2
fi

MAJOR="$(echo "$VERSION" | cut -d. -f1)"
MINOR="$(echo "$VERSION" | cut -d. -f2)"
PATCH="$(echo "$VERSION" | cut -d. -f3)"

# Only vCenter 7.0.x and 8.0.x are in scope for this advisory.
if [ "$MAJOR" = "7" ] && [ "$MINOR" = "0" ]; then
  if [ -z "$BUILD" ]; then
    echo "UNKNOWN: detected vCenter $VERSION but no build number was parseable"
    exit 2
  fi
  if [ "$BUILD" -lt "$VC7_FIXED_BUILD" ]; then
    echo "VULNERABLE: vCenter $VERSION build $BUILD is older than 7.0 U3v build $VC7_FIXED_BUILD"
    exit 1
  else
    echo "PATCHED: vCenter $VERSION build $BUILD meets or exceeds 7.0 U3v build $VC7_FIXED_BUILD"
    exit 0
  fi
elif [ "$MAJOR" = "8" ] && [ "$MINOR" = "0" ]; then
  if [ -z "$BUILD" ]; then
    echo "UNKNOWN: detected vCenter $VERSION but no build number was parseable"
    exit 2
  fi
  if [ "$BUILD" -lt "$VC8_FIXED_BUILD" ]; then
    echo "VULNERABLE: vCenter $VERSION build $BUILD is older than 8.0 U3e build $VC8_FIXED_BUILD"
    exit 1
  else
    echo "PATCHED: vCenter $VERSION build $BUILD meets or exceeds 8.0 U3e build $VC8_FIXED_BUILD"
    exit 0
  fi
else
  echo "PATCHED: version $VERSION is outside the affected 7.0.x / 8.0.x ranges checked by this script"
  exit 0
fi

Sources

1. Tenable plugin 237247
2. Broadcom VMSA-2025-0010
3. NVD CVE-2025-41225
4. CVE.org record
5. CISA KEV catalog
6. Shodan vCenter search
7. vCenter build history
8. Azure VMware Solution build reference