A hypervisor is the machine that owns the machines.

Run a community cloud on Proxmox and root on the hypervisor is root over every guest on it — the Matrix homeserver, the Nextcloud instance, the backup server, the whole stack, plus every credential those systems hold. On September 1, 2026, Proxmox published PSA-2026-00043-1: an authentication bypass, tracked as CVE-2023-54391, affecting Proxmox VE 7.0 through 8.0.3, confirmed exploited in the wild, with public proof-of-concept code.

The whole exploit is one HTTP request:

```http POST /api2/json/access/ticket HTTP/1.1 Host: :8006 Content-Type: application/x-www-form-urlencoded

username=root@pam&password=x&tfa-challenge=1 ```

No password. No second factor. The response carries a full root@pam ticket, a CSRF prevention token, and the complete root privilege map — the same authority an admin gets after a real login. The only prerequisites are a reachable API port (8006) and any enabled account without a second factor configured; by default that includes root@pam itself. One unauthenticated request and the attacker is the cluster.

What Actually Happened, on the Record

Proxmox's advisory is honest about the timeline, and the timeline is the story.

The vulnerable code shipped with the tfa-challenge parameter in PVE 7.0 (2021). The fix landed in libpve-access-control 8.0.4 on July 20, 2023 — as a side effect of reworking TFA configuration handling for an unrelated issue. Proxmox states plainly that at the time, the bypass was not known: the rework was not a security fix, the bug had neither been found internally nor reported, and it was therefore never considered for a backport to the PVE 7 branch. No CVE was assigned. No advisory was published. The changelog entry reads like plumbing:

Lookup of second factors is no longer tied to the 'keys' field in the user.cfg. This fixes an issue where certain LDAP/AD sync job settings could disable user-configured 2nd factors.

For three years, that sentence was the entire public record of a pre-auth root bypass.

The gap closed in August 2026, and the way it closed matters. A user posted unusual authentication behavior to the Proxmox forum on August 5. On August 30, Nathan Xavier Golez reconstructed the bypass by diffing AccessControl.pm across every release from 7.0 to 9.1.1, confirmed it in a lab, and reported it through Proxmox's PGP-encrypted security channel with a working PoC. Proxmox says it received many independent reports within two days — the advisory credits Kamil Rakowski, Nathan Xavier Golez, Sagnik Sasmal, "and various LLMs" — several reporting exploitation in the wild. The formal advisory followed on September 1. Someone assigned CVE-2023-54391 the same day, retroactive to the year the bug died.

Between July 2023 and September 2026, the window was open for anyone who knew: EOL 7.x installations with port 8006 reachable. Nobody was looking, because nothing announced itself. That is what a silent fix buys the attacker.

The Failure Mode: Fixes That Don't Look Like Fixes

The uncomfortable part is not that Proxmox shipped a bug. Every vendor does. It is that the fix shipped as a functional change, the changelog described the symptom, and the security consequence went uncategorized for three years.

This is a recognized blind spot in vulnerability management: security-relevant changes that land as ordinary maintenance get no advisory, no CVE, no backport decision, and — most damaging — no memory. The next vulnerability team to triage "is this worth porting to the EOL branch?" had no flag telling them the answer was yes. The 8.0.4 entry literally says "this fixes an issue where certain LDAP/AD sync job settings could disable user-configured 2nd factors." Nothing in that sentence predicts a full authentication bypass, because the bypass wasn't known at the time. But the change closed an unauthenticated path to a root-equivalent ticket, and nobody knew.

There is an uncomfortable asymmetry to sit with. When Proxmox finally learned of the flaw — from multiple independent reporters, some reporting live exploitation — it published within roughly a day, including a stop-gap sed-patch for EOL installs it no longer supports. That is a good response to a late report. The failure was upstream of it: a disclosure process that treats "we fixed something security-relevant without knowing it" as a non-event. The bug was not found in 2023. It was not found in 2024, 2025, or the first half of 2026. It was found in 2026 because a forum post about odd login behavior got read closely by someone willing to diff Perl across five years of releases.

The Operator's Checklist

Proxmox states that no supported release is affected, and that users with any second factor configured are not affected. If you operate Proxmox anywhere, tonight's checklist:

  1. Check the package, not the product. Advisory applies to libpve-access-control >= 7.0-7 and < 8.0.4. Versions only correlate loosely with the VE version, so run: dpkg-query -W -f '${Version}\n' libpve-access-control. Anything below 8.0.4 is vulnerable regardless of which VE box it wears.
  2. 8.0.4+ / 9.x: you are not affected by this bug. Stay current. This advisory is exactly what the supported branch buys you.
  3. On EOL 7.x and cannot upgrade this week: restrict port 8006 to trusted networks immediately, configure a second factor for every account that can log in (TFA users are unaffected), and consider Proxmox's official stop-gap patch from the advisory, which restores challenge validation. Then plan the upgrade anyway — the advisory's own closing note is that 7.x has missed three years of kernel, QEMU, and LXC fixes.
  4. Audit for compromise, not just exposure. This bug is being exploited in the wild with public PoC. If 8006 was internet-reachable on a 7.x host, the working assumption is that someone walked through. Look for unexpected tickets, new users, API tokens, and cron entries in guests. A hypervisor backdoor is not an incident you can patch retroactively — the guests were always the prize.

What This Means for Community Infrastructure

The community cloud pattern this site exists for — a fire hall, a co-op, a small city running its own stack on Proxmox — runs on exactly this kind of setup: one or two hosts, no dedicated security team, port 8006 reachable from the office LAN if not from the internet. The people maintaining it are volunteers. The advisory's prerequisites describe them precisely: no second factor configured, EOL version left in place because it works, API port reachable because nobody thought about it.

The defense is boring and it is the same defense this site keeps coming back to: stay on a supported release, put 8006 behind a firewall or VPN, turn on two-factor for every admin account. None of it is novel. All of it was sufficient here — the advisory's own words: users with a second factor configured are not affected, and no supported release is affected.

The deeper lesson is about EOL itself. End-of-life does not mean the software stops working; it means the vendor stops telling you when it is unsafe. The PVE 7 bug was live, silently patched in a supported branch, and invisible for three years. The operator of an EOL host had no advisory to read, no CVE to grep for, no changelog line that meant anything. When the exploit finally went public, the affected operators learned about their own vulnerability from a researcher's blog post and a forum thread — the same day the exploit code went public too.

EOL is not a state. It is a countdown you are inside of, and nobody tells you the time.

Sources: PSA-2026-00043-1 (Proxmox Security Advisory, 2026-09-01), CVE-2023-54391, Nathan Xavier Golez's analysis, SecurityOnline coverage.