CVE-2023-54391 Security Alert: CRITICAL Vulnerability

Urgent: CVE-2023-54391 requires immediate attention.

· 7 min read

Executive Summary

CVE-2023-54391 is a critical authentication bypass in Proxmox Virtual Environment (VE) 7.0 through 8.0 affecting libpve-access-control before 8.0.4. An unauthenticated attacker can send a crafted POST request to the API login endpoint with an arbitrary tfa-challenge value and skip password verification entirely, potentially logging in as root@pam or any other enabled user without a configured second factor.

This is especially dangerous for solo developers and small teams because Proxmox often sits at the center of lab, backup, VM, and container infrastructure. Even though this vulnerability is not currently known to be exploited in the wild and is not in CISA KEV, the impact is severe: full administrative takeover of affected hosts is possible if they are exposed or reachable by an attacker.

Important: all affected releases are end of life. Treat this as an urgent migration and containment issue, not just a routine patch.

Immediate Action

  • Isolate exposed Proxmox nodes now. Restrict access to the web UI and API to trusted admin IPs/VPN only; block public internet access immediately.
  • Upgrade off affected releases. Move to a supported Proxmox VE release that includes libpve-access-control 8.0.4+ or a vendor-fixed build. If you cannot patch immediately, plan a fast migration to a supported platform.
  • Rotate credentials and tokens. Assume any exposed node may have been compromised; reset admin passwords, API tokens, SSH keys, and any secrets stored on the host.
  • Review login and API logs. Look for unexpected successful logins, especially to root@pam, and any API activity from unfamiliar IPs.
  • Disable or limit remote admin access. If possible, place the management interface behind a VPN or bastion host until remediation is complete.
  • Read the vendor advisory: Proxmox security advisory.

Affected Versions

  • Proxmox VE 7.0 through 8.0 are vulnerable.
  • libpve-access-control < 8.0.4 is vulnerable.
  • Proxmox VE 8.0.4+ is the safe baseline referenced in the advisory.
  • All affected releases are end of life; upgrade to a supported release path as soon as possible.

Resolution Guide

Proxmox-specific fix: update the affected package and then verify the installed version.

# Debian/apt-based Proxmox hosts
apt update
apt policy libpve-access-control
apt install --only-upgrade libpve-access-control

# If the vendor repo is configured, upgrade the full stack
apt full-upgrade

# Verify installed version
dpkg -l | grep libpve-access-control
pveversion -v

yum/dnf systems are not the standard Proxmox platform, but if you are managing a similar appliance or mirrored package set, use the vendor-supported update path:

dnf update
rpm -q libpve-access-control

Docker / image-based deployments: rebuild from a fixed base image and redeploy; do not patch running containers in place.

# Example: rebuild with a fixed base image tag
docker build --no-cache -t your-registry/proxmox-admin:fixed .

# Redeploy the new image
docker compose pull
docker compose up -d --force-recreate

JavaScript / Python / Maven / Gradle are not directly applicable to Proxmox itself, but if you have tooling that talks to the Proxmox API, update those clients and remove any code that assumes the login endpoint is trustworthy:

# npm/yarn/pnpm examples for API client tooling
npm i your-proxmox-client@latest
yarn add your-proxmox-client@latest
pnpm add your-proxmox-client@latest

# Python examples
pip install --upgrade your-proxmox-client
pipx upgrade your-proxmox-client

# Maven/Gradle examples
# TODO: replace with your actual client coordinates
mvn versions:use-latest-releases
./gradlew dependencyUpdates

Hardening examples:

# Restrict the Proxmox web UI/API to trusted admin networks only
ufw allow from 10.0.0.0/24 to any port 8006 proto tcp
ufw deny 8006/tcp

# Example reverse proxy access control
# TODO: adapt to your proxy
allow 10.0.0.0/24;
deny all;

Minimal code/automation fix example: if you have scripts that automate Proxmox login, fail closed when 2FA behavior is unexpected and never trust arbitrary challenge values.

# Pseudocode: reject login flows that do not complete a real password + TFA check
if login_response.indicates_tfa_challenge and challenge_value_is_untrusted:
    raise SecurityError("Refusing unsafe Proxmox login flow")

Detection & Verification

Check version exposure:

pveversion -v
dpkg -l | egrep 'pve-manager|libpve-access-control'
apt-cache policy libpve-access-control

Look for suspicious authentication events:

# Proxmox auth logs
grep -R "root@pam\|successful login\|ticket" /var/log/pveproxy* /var/log/auth.log /var/log/syslog 2>/dev/null

# Recent API access patterns
grep -R "access/ticket\|tfa-challenge" /var/log/pveproxy* 2>/dev/null

Verify the fix:

# Confirm the vulnerable package is no longer present
dpkg -l | grep libpve-access-control

# Confirm the host is on a supported, vendor-fixed release
pveversion -v

# Optional: test from a trusted admin host that login requires valid credentials
curl -k -X POST https://YOUR-PVE:8006/api2/json/access/ticket \
  -d "username=root@pam" \
  -d "password=INVALID" \
  -d "tfa-challenge=INVALID"

Dependency auditors: if you maintain internal tooling or wrappers, search for Proxmox API login code and verify it does not accept arbitrary tfa-challenge values or suppress authentication errors.

Risk and Impact

Successful exploitation can give an attacker full administrative access to the Proxmox host, including VM and container control, storage access, backups, network configuration, and host-level secrets. In a small environment, that can mean complete loss of infrastructure, data theft, ransomware deployment, or destruction of backups. Because the flaw bypasses authentication entirely, exposed management interfaces should be treated as high-risk until patched and access-restricted.

Keep reading