Proxmox VE 7 and the Authentication Bypass That Was Fixed by Accident in 2023

Some vulnerabilities are found by researchers. This one was closed by a refactor nobody recognized as a security fix, then rediscovered three years later on an end-of-life branch that never received it. The result is a passwordless path to root on Proxmox VE installations that are still running.

What the vulnerability is

Proxmox VE is a virtualization platform used to run virtual machines and containers. Its management interface listens on port 8006 by default. The flaw, published as PSA-2026-00043-1, is an authentication bypass in the libpve-access-control component affecting PVE 7.x through 8.0.3.
The mechanism involves the multi-factor authentication flow. When 2FA is enabled, a user who submits a correct password receives a signed tfa-challenge ticket and must present it to complete the second factor. In the affected code, the validation of that ticket was not performed correctly for accounts without 2FA configured. If the tfa-challenge parameter was present at all, the normal password verification step was skipped.
An attacker who can reach the API on port 8006 can therefore supply any username and an arbitrary ticket value and authenticate without a password. The default administrative account, root@pam, typically has no 2FA configured, so a default installation is affected.

The accidental fix

On 20 July 2023, Proxmox released PVE 8.0.4. That release refactored the handling of TFA configuration. The refactor incidentally closed the bypass path. The development team was not aware the vulnerability existed, so the change was treated as an ordinary functional fix. No security advisory was issued, and the change was not backported to the PVE 7 series, which was still maintained at the time.
The flaw was rediscovered in late August 2026 when a security researcher analyzed code differences between versions. Proxmox confirmed that all currently supported versions are unaffected and that the older branch has no available security patch because it has reached end of life.

Observed exploitation

Proxmox confirmed receiving multiple independent reports of attackers using the vulnerability to gain access to instances and then encrypt data for extortion. This is not a theoretical exposure. The exploitation method has been published publicly, which the vendor notes will likely accelerate attacks.
A concrete case illustrates the exposure pattern. A hosting provider's infrastructure was found to be running PVE 7 without the vulnerability remediated or the 2FA validation workaround applied, after the advisory had been published. Because the affected hosts could be located through network observation platforms, locating and targeting them required little more than a script to iterate over observed addresses.

Affected versions and remediation

The affected range is PVE 7.x through 8.0.3, which in practice covers the 7.0 to 7.4 series and early 8.0 releases. Proxmox states that PVE 8.2 and 8.4 are not affected.
For supported versions, upgrading to 8.0.4 or later resolves the issue. For the end-of-life PVE 7 branch, there is no vendor patch. Two options exist.
The first is to enable 2FA for root@pam and any other administrative accounts. This closes the bypass because the generated tfa-challenge tickets are then genuine and cannot be forged with an arbitrary value. It is a configuration change rather than a code change, and it works on the unsupported branch.
The second is the vendor's stop-gap modification to AccessControl.pm to enforce validation of the tfa-challenge signature, followed by a restart of the affected services. Proxmox describes this as a temporary measure and recommends upgrading.
Independently of either option, port 8006 should not be reachable from the public internet. Removing that exposure eliminates the attack path regardless of patch state.

Why the timeline matters more than the bug

The interesting feature of this case is not the code defect. Authentication logic that skips a check when a parameter is present is a familiar class of error. What makes the case instructive is the three-year interval in which the vulnerability existed, was accidentally fixed on one branch, and remained live on another.
Three conditions produced that interval:

The fix was incidental, so no advisory was generated and no one knew to backport it.
The affected branch reached end of life before the flaw was recognized, removing the normal patch path.
The vulnerable service was, in at least one observed case, reachable from the internet and discoverable through network scanning. The third condition is the one defenders control directly. A management interface that is reachable from the internet converts every unpatched authentication flaw from a theoretical issue into an operational one.

Verification steps

For environments that ran an affected version while exposed:

Confirm the PVE version and whether port 8006 was reachable from outside the trusted network.
Review authentication logs for successful root@pam logins that do not correspond to known administrative activity.
Check for scheduled tasks, unfamiliar users and outbound connections that were not configured by the operations team.
Treat data integrity as suspect if unauthorized root access is confirmed, since root on a hypervisor reaches every hosted virtual machine and container.

Limits of the current picture

The vendor has confirmed exploitation and data encryption. The public record does not establish how many instances were affected, whether all reported incidents used the same method, or how the attackers selected targets. Proxmox has also noted user reports of attacks against 8.2 and 8.4 installations, but states there is no evidence those versions are affected by this specific flaw; those reports may involve other causes.