Subject: PSA-2026-00043-1: Authentication bypass in EOL Proxmox VE 7 release
Advisory date: 2026-09-01
Packages: libpve-access-control
Affected: libpve-access-control >= 7.0-7 and < 8.0.4
Roughly corresponding to Proxmox VE 7.0 up to and including 7.4 (end of life since July 2024), and, for completeness, the initial Proxmox VE 8.0 (EOL), as the fix only shipped roughly one month after that release.
Package versions and the overall Proxmox VE version only correlate loosely, since dependency versions are only raised when needed. To determine whether an installation is affected, check the installed package version, not the overall Proxmox VE version:
dpkg-query -W -f '${Version}\n' libpve-access-control
Alternatively
pveversion -v lists the versions of all installed Proxmox VE packages - look for the version of libpve-access-control.
Fixed in: libpve-access-control 8.0.4 (released 2023-07-20) and all later versions. No supported Proxmox VE release is affected.
Details:
The API login call (POST /api2/json/access/ticket) accepts a 'tfa-challenge' parameter. It carries the signed, half-authenticated TFA challenge ticket that a client receives when logging in as a user with two-factor authentication, and is used to complete the second factor.
In the affected versions, this parameter was not validated for users without configured second factors, while its presence also caused the verification of the submitted password to be skipped entirely. As a result, an attacker with access to the API could authenticate as any existing, enabled user without configured second factors (by default this includes root@pam), without knowing any credentials, by passing an arbitrary value in the 'tfa-challenge' parameter.
Exploitation requires access to the API port (8006), directly or through a reverse proxy. Restricting API access to trusted networks has always been our recommended setup.
Timeline:
The vulnerable code path was closed in July 2023, with libpve-access-control 8.0.4, as a side effect of a rework of the TFA configuration handling for an unrelated issue. At that time, the authentication bypass was not known: the rework was not a security fix, and the issue had neither been found internally nor reported. It was therefore not recognized as a candidate for a backport to the PVE 7 branch.
We learned of the issue now, through many independent reports within the last two days, which also report exploitation in the wild. Given the severity of the issue we are publishing this advisory for the affected end-of-life releases, including a stop-gap mitigation for installations that cannot upgrade right away.
The issue was independently reported by:
* Kamil Rakowski <
kamil@kamilrak.com>
* Nathan Xavier Golez <
nathan@nathangolez.com>
* Sagnik Sasmal <
sagnik@sagnik.me>
* various LLMs
Mitigation:
Installations whose API is not reachable by potential attackers are not exposed. Further, users with any second factor configured for login are not affected.
For installations that cannot upgrade right away, the following patch adds a validation step to the affected code path: every 'tfa-challenge' value must then be a valid, signed TFA challenge ticket, which an attacker cannot forge. Normal password logins and two-factor logins keep working.
Bash:
sed -i.bck 's/^\t# This is the 2nd factor, use the password for the OTP response.$/\tverify_ticket($tfa_challenge, 0, $username);\n\t# This is the 2nd factor, use the password for the OTP response./' /usr/share/perl5/PVE/AccessControl.pm
grep -n 'verify_ticket($tfa_challenge, 0, $username)' /usr/share/perl5/PVE/AccessControl.pm | wc -l
systemctl reload-or-restart pvedaemon pveproxy
The grep command must print 3 (occurrences of the verify_ticket line in the file). If it prints anything else, the patch did not apply and the installation is still vulnerable. To undo the patch, restore the '.bck' backup file and restart both services again.
Upgrading to a supported Proxmox VE release is the only durable fix: the affected releases are end of life and have not received the security fixes shipped since then, both for the PVE stack itself and for components such as the Linux kernel, QEMU or LXC, among others.
