Proxmox Virtual Environment

CVE-2023-54391 is an authentication bypass in libpve-access-control (versions 7.0-7 through before 8.0.4) shipped with Proxmox Virtual Environment 7.0–7.4 and the initial 8.0 release. A single unauthenticated POST to /api2/json/access/ticket with an arbitrary tfa-challenge value causes the server to skip password verification entirely and issue a valid session ticket for *any enabled account* — including root@pam. No credentials, no brute-force, no user interaction. The attacker lands directly on the hypervisor management plane with full control of every VM, container, and storage backend. The fix shipped silently in libpve-access-control 8.0.4 in July 2023 as part of a TFA code rework; the security implications weren't formally disclosed until advisory PSA-2026-00043-1 on 1 September 2026.

The vendor's CVSS 9.8 / CRITICAL rating is accurate and, if anything, generous in how calmly it states the situation. This is a zero-click, zero-knowledge, unauthenticated full takeover of a *hypervisor* — the single most privileged tier in a virtualized stack. The only population limiter is that all affected versions are now end-of-life (PVE 7 EOL July 2024, PVE 8.0 superseded). But EOL doesn't mean gone: community reports, Shodan data (~25,000 internet-facing Proxmox instances on port 8006), and the post-VMware migration wave suggest a meaningful tail of PVE 7.x boxes still running in production. The vendor confirmed learning about active exploitation through multiple independent reports within 48 hours of disclosure.

Why this verdict

• Zero-friction exploit chain: Single unauthenticated HTTP POST, no credentials needed, no user interaction, deterministic success. Public PoC is a curl one-liner.
• Role multiplier — hypervisor is the highest-value tier: Proxmox VE is *by definition* a hypervisor. Compromise of root@pam grants control over every VM, container, storage backend, and cluster peer. Blast radius is fleet-scale: one exploited host = every workload on that host and potentially the entire cluster.
• Active exploitation confirmed: Proxmox acknowledged in-the-wild attacks within 48 hours of disclosure. Community reports of encrypted hosts on hosting providers.
• Default configuration is vulnerable: Accounts without MFA (the out-of-box default for all Proxmox accounts including root@pam) are exploitable. No non-default hardening is required to be at risk.
• Internet exposure is real: ~25,000 Proxmox management interfaces indexed on Shodan. Even internal-only instances are reachable by any attacker with LAN access (post-phish, post-VPN compromise).

Why not higher?

The vendor already assigned CVSS 9.8 — there is no higher standard severity bucket. The only theoretical cap-breaker would be a wormable Scope:Changed vector, which this is not (S:U).

Why not lower?

Every downgrade argument fails the floor test. EOL-only versions affected narrows the population but does not change blast radius: a single vulnerable Proxmox host still means total hypervisor compromise. The component is canonically a hypervisor (100% of installs are high-value-role), exploitation is confirmed in the wild, and the PoC is trivial. Friction is effectively zero for any reachable instance with default config. Downgrading below CRITICAL would require evidence that fewer than 1% of the installed base remains on PVE 7.x — no such data exists, and community/forum activity suggests otherwise.

1. Block port 8006 from all untrusted networks immediately — Restrict Proxmox management API access to a dedicated management VLAN or VPN-only. This is the single highest-impact control: if attackers can't reach the API, the exploit fails. Deploy within the noisgate mitigation SLA of ≤ 3 days.
2. Enforce MFA on all Proxmox accounts, especially root@pam — Accounts with a configured second factor (TOTP, U2F, or WebAuthn) are not exploitable via this path. Enable MFA on every account in the PVE realm configuration. This is a durable control even before patching. Deploy within 3 days.
3. Disable or rename root@pam if operationally feasible — Create a named admin account with MFA, assign PVEAdmin role, and disable direct root@pam login via PAM configuration. Eliminates the highest-value target account.
4. Deploy WAF or reverse-proxy rule to block tfa-challenge in unauthenticated ticket requests — If a reverse proxy sits in front of Proxmox, add a rule to reject POST requests to /api2/json/access/ticket containing the tfa-challenge parameter when no prior authenticated session exists. This is a surgical block for this specific exploit.
5. Upgrade to Proxmox VE 8.2+ or 9.x — The only true remediation is upgrading off EOL. libpve-access-control 8.0.4+ is fixed, but PVE 7.x and initial 8.0 are end-of-life and will receive no further patches for *any* vulnerability. Plan and execute migration within the noisgate remediation SLA of ≤ 90 days.

Run this script on each Proxmox VE host as root (or any user with read access to dpkg). Invoke with: sudo bash check_cve_2023_54391.sh. No arguments needed. Returns exit code 0 for PATCHED, 1 for VULNERABLE, 2 for UNKNOWN.

#!/usr/bin/env bash
# check_cve_2023_54391.sh — Detect CVE-2023-54391 (Proxmox auth bypass)
# Run on the Proxmox VE host as root or with dpkg read access.
# Exit codes: 0 = PATCHED, 1 = VULNERABLE, 2 = UNKNOWN

set -euo pipefail

PKG="libpve-access-control"
FIXED="8.0.4"

# Check if this is a Proxmox host
if ! command -v pveversion &>/dev/null; then
  echo "UNKNOWN — pveversion not found; this may not be a Proxmox VE host."
  exit 2
fi

# Get installed version of libpve-access-control
INSTALLED=$(dpkg-query -W -f='${Version}' "$PKG" 2>/dev/null || true)

if [ -z "$INSTALLED" ]; then
  echo "UNKNOWN — $PKG is not installed."
  exit 2
fi

echo "Detected $PKG version: $INSTALLED"
echo "Fixed version: >= $FIXED"

# Compare versions using dpkg
if dpkg --compare-versions "$INSTALLED" ge "$FIXED"; then
  echo "PATCHED — $PKG $INSTALLED is at or above the fix ($FIXED)."
  exit 0
else
  echo "VULNERABLE — $PKG $INSTALLED is below the fix ($FIXED). CVE-2023-54391 applies."
  # Additional check: is MFA configured on root@pam?
  if command -v pveum &>/dev/null; then
    TFA_COUNT=$(pveum user tfa list root@pam 2>/dev/null | grep -c 'totp\|u2f\|webauthn' || true)
    if [ "$TFA_COUNT" -gt 0 ]; then
      echo "NOTE: root@pam has $TFA_COUNT TFA method(s) configured — partially mitigated."
    else
      echo "WARNING: root@pam has NO TFA configured — fully exploitable."
    fi
  fi
  exit 1
fi

Sources

1. BlackTree — A Three-Year-Old Proxmox Fix Just Became an Emergency
2. SecurityOnline — Proxmox VE 7 Auth Bypass: PoC Public, Exploited in the Wild
3. VulnCheck Advisory — Proxmox VE Authentication Bypass via tfa-challenge Parameter
4. GitHub Advisory Database — GHSA-m457-grcf-698x
5. IONIX Threat Center — CVE-2023-54391
6. nFlo Knowledge Base — CVE-2023-54391 Authentication Bypass
7. runZero — Managing End-of-Life Proxmox Hypervisors
8. Proxmox Support Forum — PVE 7 Vulnerability Discussion