DEV Community

kozhevniko
kozhevniko

Posted on

The Bug That Sat Fixed for Three Years: Proxmox VE's Authentication Bypass and the Cost of Unsupported Hypervisors

The Bug That Sat Fixed for Three Years: Proxmox VE's Authentication Bypass and the Cost of Unsupported Hypervisors

In late August 2026, Proxmox published security advisory PSA-2026-00043-1 describing an authentication bypass in Proxmox Virtual Environment. The flaw lets an attacker who can reach the PVE API on its default port 8006 log in as an existing user without knowing that user's password. Because the default administrator account, root@pam, normally has no second factor configured, a default installation is exposed. Proxmox confirmed multiple independent reports of attackers using the flaw to gain access and encrypt data for extortion.

How the bypass works

The vulnerable component is libpve-access-control. When multi-factor authentication is enabled, a user first submits a password and receives a signed tfa-challenge ticket, which is then presented to complete the second factor. In the affected code, the check that the ticket is genuinely signed was not enforced for accounts that have no 2FA configured. The mere presence of the tfa-challenge parameter caused the normal password verification path to be skipped.
An attacker therefore needs only a valid username and any value for that parameter. No password, no valid ticket, no cryptographic material. The default root@pam account is the natural target.

A three-year-old accidental fix

The most instructive part of this story is the timeline. Proxmox refactored its TFA configuration handling in version 8.0.4, released on 20 July 2023, and that refactor incidentally closed the bypass. The development team did not know a vulnerability existed, so the change shipped as an ordinary functional fix. No security advisory was issued, and the fix was never backported to the PVE 7 branch that was still maintained at the time.
The flaw was rediscovered in late August 2026 when a researcher compared code across versions. By then, PVE 7 had reached end of life, so there is no vendor patch for the branch most affected. Proxmox states that all currently supported versions are unaffected.

Why this matters beyond Proxmox

Two general lessons emerge.
The first is that an unsupported version is not merely unpatched; it is unpatched for bugs nobody has looked for yet. PVE 7 users are running code that received its last security review years ago. The 2023 refactor is a reminder that fixes can land silently and never reach the branches that need them.
The second is that authentication bypasses are the highest-leverage class of bug on an infrastructure management plane. A hypervisor console controls every guest, every snapshot, and every stored credential on the host. Reaching it as root is not a step in an intrusion; it is the end of one.

What to do

Upgrade to a supported PVE release. This is the only complete fix, and for PVE 7 it means a version upgrade rather than a patch.
If you must stay on PVE 7.x or 8.0.x temporarily, apply the vendor's stop-gap: modify AccessControl.pm so that the tfa-challenge signature is actually verified, then restart the affected services. Proxmox describes this as temporary and still recommends upgrading.
Enforce a second factor on root@pam. Once a real 2FA enrollment exists, the generated tickets are genuine and the bypass path is closed. This is a small configuration change with an outsized effect.
Remove port 8006 from the public internet. A hypervisor management API has no business being reachable from arbitrary addresses. Put it behind a management network or a VPN.
Check for compromise. If an instance was exposed and unpatched, review authentication logs for successful root@pam logins that do not correspond to known administrative activity, and look for unexpected scheduled tasks or encryption activity.

References

Top comments (0)