tfa-challenge Authentication Bypass in Proxmox Server Solutions GmbH Proxmox Virtual Environment (VE)

Proxmox Virtual Environment (VE) 7.0 through 8.0 contains an authentication bypass vulnerability in libpve-access-control before 8.0.4 that allows unauthenticated attackers to authenticate as any existing enabled user without a configured second factor by supplying an arbitrary tfa-challenge value in the API login endpoint. Attackers can send a POST request to the access ticket API endpoint with any value in the tfa-challenge parameter to completely skip password verification, gaining unauthorized access including to the root@pam account. All affected releases are end of life.

• libpve-access-control versions from 7.0-7 inclusive and before 8.0.4 are affected.
• The corresponding product scope is Proxmox Virtual Environment (VE) 7.0 through 7.4 inclusive, and the initial Proxmox VE 8.0 release.
• All affected releases are end of life.
• libpve-access-control 8.0.4 fixes the issue; the Proxmox advisory states that this version and all later releases are fixed. No supported Proxmox VE release is affected.

Proxmox Server Solutions GmbH Proxmox Virtual Environment (VE) processes API login through POST /api2/json/access/ticket, where tfa-challenge is used to complete TFA. In affected versions, this value was not validated for users without a configured second factor, while the presence of the parameter also caused password verification to be skipped entirely. An attacker could therefore authenticate as any existing enabled user without a second factor by supplying an arbitrary tfa-challenge value, without knowing valid credentials. Exploitation requires reachability to the API, directly or through a reverse proxy, on port 8006. This is CWE-304, Missing Critical Step in Authentication; the available evidence does not establish that every deployment exposes this API to the Internet.

The vulnerability is remotely exploitable over the network with a single API request, without prior authentication and without user interaction. The attacker must be able to reach the Proxmox API on port 8006 or through a reverse proxy, but does not need existing privileges or a valid password. The target must be an existing enabled account without a configured second factor; according to the vendor advisory, this can include root@pam by default. Proxmox reports receiving multiple independent reports of exploitation in the wild. The available evidence does not name a specific campaign or victim and does not confirm an independent publicly available exploit.

An attacker can complete authentication under the identity of an enabled account without a valid password or second factor. The resulting privilege depends on the target account; if it has administrative permissions, the attacker could read or modify management data, control virtualization resources, and potentially disrupt workloads. Targeting root@pam could produce broad administrative impact. The impact requires API reachability and a target account without a configured second factor; deployments that do not meet both conditions have a different exposure profile.

The vulnerability can allow an unauthenticated person to operate with the permissions of a selected Proxmox account. The practical consequences depend on that account's privileges, but access as root@pam could provide broad administrative control over the virtualization environment. Possible consequences include disclosure of management or workload data, unauthorized changes to virtual resources and configuration, and service disruption. The advisory does not establish that every system was compromised, but Proxmox reports multiple exploitation reports from the wild.

1. Upgrade first. Move off the end-of-life Proxmox VE releases to a supported Proxmox VE release, and verify that libpve-access-control is 8.0.4 or a later release.
2. Check the installed package with dpkg-query -W -f '${Version}\n' libpve-access-control or review pveversion -v. Package versions and the overall Proxmox VE version correlate only loosely, so the overall VE version must not be used as the only exposure check.
3. If an immediate upgrade is not possible, restrict API port 8006 to trusted networks, either directly or at the reverse proxy. The vendor states that installations whose API cannot be reached by potential attackers are not exposed through this path.
4. Ensure that accounts used for login have a configured second factor. This reduces exposure to this vulnerability but does not replace upgrading.
5. For systems that cannot be upgraded immediately, apply the vendor's stop-gap validation patch so every tfa-challenge value must be a valid signed TFA challenge, then reload or restart pvedaemon and pveproxy. Verify the patch using the specified count of three verify_ticket($tfa_challenge, 0, $username) occurrences before treating the system as protected.

1. Check the installed package directly with dpkg-query -W -f '${Version}\n' libpve-access-control; do not determine exposure from the overall Proxmox VE version alone.
2. Use pveversion -v if needed to review the installed libpve-access-control version alongside other Proxmox packages.
3. Review enabled accounts that lack a configured second factor, especially root@pam, and determine which networks can reach API port 8006.
4. If the vendor stop-gap patch was applied, check for verify_ticket($tfa_challenge, 0, $username) in AccessControl.pm; the advisory specifies that the validation should show three occurrences.
5. Review authentication and API logs for unusual logins or access-ticket issuance, particularly activity that does not match expected users. This is precautionary monitoring, not a vendor-published CVE-specific indicator; the absence of suspicious logs does not prove that the system is safe.