Introduction
CVE-2023-54391 represents a critical pre-authentication authentication bypass vulnerability in Proxmox Virtual Environment (PVE). Operating at a CVSS 3.1 score of 9.8 (Critical), this security flaw allows unauthenticated remote attackers to completely bypass standard password authentication mechanisms. By manipulating parameters in the login API endpoint, an attacker can gain full superuser (root@pam) access to the underlying hypervisor management plane without knowing the victim account’s password. The flaw specifically resides within the libpve-access-control package’s handling of the tfa-challenge parameter during the API access-ticket creation process. When an arbitrary challenge value is supplied for an account lacking two-factor authentication, the system erroneously validates the request and skips password verification entirely. Consequently, any Internet-exposed management interface becomes vulnerable to immediate, full administrative compromise and remote code execution.
Learning Objectives
- Understand the vulnerability scope: Learn how logic flaws in API authentication workflows can compromise identity management systems.
- Analyze the attack vector: Identify how input manipulation in the HTTP POST authentication payload bypasses credential verification.
- Recognize affected components: Identify vulnerable legacy versions of the
libpve-access-controlpackage and Proxmox VE releases. - Implement remediations: Apply strict access controls, system updates, and explicit two-factor authentication requirements to mitigate exposure.
What is Proxmox VE – Default Credentials with TFA Bypass (CVE-2023-54391)
Proxmox VE relies heavily on the libpve-access-control package to validate administrative tickets via its management API (typically exposed on TCP port 8006). This component serves as the central identity gateway, handling authentication requests, multi-factor challenges, and access token distribution across the hypervisor cluster. CVE-2023-54391 stems from a critical logic flaw within this authentication routine, specifically regarding how the system processes two-factor authentication (2FA/TFA) challenge parameters during incoming user login requests. When authenticating against standard administrative accounts like root@pam, the application’s backend code attempts to route the request through a multi-step verification pipeline. However, if an HTTP POST request is submitted containing an arbitrary tfa-challenge parameter, libpve-access-control incorrectly short-circuits the evaluation logic. Instead of verifying the primary password first and then validating the second factor, the service jumps directly into assessing the state of the two-factor challenge token.
For target accounts that do not have an active 2FA second-factor configured (which is the default state for freshly installed Proxmox instances), the system encounters an unhandled edge case. Because no registered TOTP or WebAuthn keys exist to match against, the server evaluates the challenge requirement as satisfied without verifying the user’s password. The API immediately responds by issuing a valid session ticket (PVEAuthCookie) and CSRF prevention token, granting remote attackers unauthenticated, high-privilege access over the hypervisor node.
- Target API Endpoint: Unauthenticated HTTP POST requests directed at
/api2/json/access/ticketon port 8006. - Parameter Manipulation: Injecting an arbitrary non-empty string into the
tfa-challengeparameter within the request payload. - Password Verification Bypass: Complete short-circuiting of the standard password authentication check by the
libpve-access-controllogic. - Impact & Reach: Immediate generation of a valid administrative session ticket for default un-configured accounts (
root@pam), granting total cluster control.
- Impact & Reach: Immediate generation of a valid administrative session ticket for default un-configured accounts (
root@pam), granting total cluster control.
+----------+ POST /api2/json/access/ticket +--------------------+
| Attacker | -----------------------------> | Proxmox VE (8006) |
+----------+ {tfa-challenge: "123"} +--------------------+
| |
| v
| [ tfa-challenge Present? ]
| | (Yes)
| v
| [ 2FA Active on Account? ]
| | (No)
| v
| Valid Ticket & CSRF Returned [ Bypass Password Check ]
| <-----------------------------------------------|
v
[ Root Access Granted ]Technical Detail: How the Vulnerability Works
The primary mechanism enabling this breach resides within the REST API endpoint responsible for ticket generation: POST /api2/json/access/ticket. In normal authentication flows, Proxmox VE inspects the primary credentials (username and password) against the specified realm (e.g., PAM or PVE internal database). Only after primary authentication succeeds does the access control module evaluate whether a secondary factor is required to finalize the issuance of the administrative PVEAuthCookie. When an attacker submits a crafted authentication request containing an arbitrary tfa-challenge string, the libpve-access-control package mistakenly branches into a secondary evaluation path prior to completing primary credential verification. The logic assumes that if a tfa-challenge value is actively present in the request body, the user has already satisfied the first stage of authentication and is now providing responses to an ongoing multi-factor challenge sequence.
Because target accounts like root@pam frequently lack pre-configured two-factor authentication devices, the system encounters an invalid conditional branch. The code checks for registered 2FA credentials associated with the user profile, finds none, and concludes that no secondary challenge verification is pending. Due to a failure to verify that primary password validation took place earlier in the call stack, the API engine returns a fully privileged administrative session ticket and CSRF token back to the unauthenticated client.
- Reconnaissance & Vector Selection: The attacker targets the web management port (TCP 8006) and issues a direct HTTP POST request targeting the
/api2/json/access/ticketREST endpoint. - Payload Structure: The request body explicitly declares the target account (
username=root@pam) alongside a dummy value injected into thetfa-challengefield, while completely omitting a valid password. - Control-Flow Short-Circuiting: The
libpve-access-controlmodule processes the incoming request, detects the challenge parameter, and incorrectly skips the primary password validation step. - Session Cookie Acquisition: The backend issues a HTTP 200 OK response containing a functional
PVEAuthCookieandCSRFPreventionToken, granting full remote administrative privileges over the hypervisor.
Affected Software & Plugins
The scope of CVE-2023-54391 centers on the core access control layer used by Proxmox Virtual Environment to authenticate users and manage cluster access. Because Proxmox VE relies on a modular Debian-based package hierarchy, the underlying vulnerability resides specifically within libpve-access-control, which handles all REST API authentication logic, ticket issuance, and multi-factor verification workflows. Systems running affected releases without active two-factor authentication remain exposed to unauthenticated remote privilege escalation. Organizations maintaining legacy environments should take note that Proxmox VE 7.x reached End-of-Life (EOL) in July 2024, leaving unpatched 7.x nodes without upstream security repository updates. Remediation requires upgrading the libpve-access-control package to version 8.0.4 or higher, migrating EOL installations to a supported Proxmox release (such as 8.4+ or 9.x), enforcing 2FA across all administrative accounts, and isolating the management web interface (port 8006) behind a secure VPN or administrative VLAN.
| Software / Core Package | Vulnerable Versions | Safe / Fixed Version | Patch Release Date | Status & Recommended Action |
|---|---|---|---|---|
| libpve-access-control | >= 7.0-7 and < 8.0.4 | 8.0.4 or later | July 2023 | Core Fix: Upgrade the package via apt update && apt install libpve-access-control. |
| Proxmox VE 7.x Branch | Versions 7.0 through 7.4 | None (Branch EOL) | Unmaintained | Critical Exposure: End-of-Life since July 2024. Perform a full distribution upgrade to PVE 8.x/9.x. |
| Proxmox VE 8.x Branch | Initial build 8.0 (prior to 8.0.4) | 8.0.4, 8.1, 8.2+ | July 2023 | Supported Branch: Run pveupgrade to pull the latest security patches from the standard repositories. |
| Proxmox VE 9.x Branch | None (Inherits patched logic) | All releases | N/A | Unaffected: Includes corrected authentication check logic by default. |
Conclusion
CVE-2023-54391 serves as a stark reminder of the inherent risks associated with exposing hypervisor management planes directly to untrusted networks. When authentication logic fails to enforce baseline credential verification before processing advanced features like two-factor authentication challenges, even robust infrastructure platforms become vulnerable to total remote compromise. A single unauthenticated HTTP request can grant attackers elevated root privileges over the entire virtualization cluster, compromising every hosted guest machine and data volume in the process. To effectively eliminate exposure, system administrators must immediately update the libpve-access-control package to version 8.0.4 or higher across all active nodes. For legacy environments running End-of-Life Proxmox VE 7.x installations, performing a full release upgrade to a supported Proxmox VE version is necessary to ensure long-term stability and security patch availability. Additionally, enabling mandatory two-factor authentication (such as TOTP or WebAuthn) for all active accounts—including the default root@pam profile—provides an extra layer of defense that neutralizes this specific short-circuit mechanism. Finally, technical remediations should be supported by strong network architecture and perimeter controls. Hypervisor web management interfaces (port 8006) should never be exposed to the public internet or untrusted internal subnets. Restricting access to dedicated, isolated management VLANs, placing interfaces behind bastion hosts, and requiring encrypted VPN tunnels ensure that critical virtualization control planes remain inaccessible to unauthorized network actors.