The Proxmox Bug Fixed in 2023 That's Rooting Hypervisors in 2026: CVE-2023-54391
The Situation
On September 1, 2026, VulnCheck assigned CVE-2023-54391 to an authentication bypass that Proxmox had already closed in July 2023. Proxmox followed with PSA-2026-00043-1. The gap is the story: the bug sat unnamed for three years on every Proxmox VE 7 host that never moved.
What it does, in one sentence: POST /api2/json/access/ticket with any tfa-challenge value skips the password check for users who have no second factor configured - including the default root@pam account - and returns a session ticket plus CSRF token.
- CWE-304 (missing critical step in authentication).
- CVSS 4.0 9.3 (VulnCheck); CVSS 3.1 9.8 (NVD).
- Unauthenticated. No password required.
- A public Nuclei template exists. We will not paste it, and you do not need it to decide what to do.
CrowdSec started matching the request shape on September 4, 2026. Between September 4 and 6 they recorded 1,210 exploit-pattern signals, 133 unique source IPs, peaking at 901 signals on September 4. That is scanning and exploit-pattern traffic, not a confirmed breach census. As of September 7, 2026 the CVE is in VulnCheck KEV and not in CISA KEV.
Independent reports of ransomware on internet-exposed PVE 7 hosts accompanied the CVE assignment. CrowdSec confirms mass scanning; it does not confirm extortion. Treat those ransom claims as secondary reporting, not as CrowdSec fact.
What's Affected
The check is the package, not the marketing version string.
| What | Status |
|---|---|
libpve-access-control < 8.0.4 |
Vulnerable |
| Proxmox VE 7.0-7.4 | Affected. EOL July 2024. No vendor backport. |
| Initial Proxmox VE 8.0 (package still < 8.0.4) | Affected until the 8.0.4 package |
| Proxmox VE 8.0.4+ and 9.x | Not affected |
| Users with 2FA enrolled | Not on the skip path |
Default root@pam |
Usually not enrolled. Assume it is in the skip path until you prove otherwise |
The fix shipped July 20, 2023 as libpve-access-control 8.0.4 (pve-access-control commit 032e7d6d) as routine 8.0 work - not as a named security backport. That is why PVE 7 never got it.
Confirm on the host:
dpkg -l libpve-access-control
dpkg-query -W -f '${Version}\n' libpve-access-control
Anything below 8.0.4 is vulnerable.
Why This Matters for VPS / Hypervisor Hosts
A ticket as root@pam is not "someone got into a panel." It is root on the hypervisor: every guest disk, every backup, every storage plugin, and in a cluster, a path toward the other nodes.
That is why this is a hosting problem, not a homelab curiosity:
- Providers still running PVE 7 because "the VMs are fine" have been sitting on an unpatched, unnamed auth bypass since 2023.
- Port 8006 on the public internet is the entire attack surface. Proxmox has recommended taking the UI off the internet for years. This CVE is what that recommendation was for.
- Guests do not need their own bug. Host root can reach into VMs that run the QEMU guest agent. Isolation you sell to customers is gone the moment the hypervisor login is gone.
- CrowdSec's sensor mix for this CVE is skewed toward France / Italy / Germany SOHO (they report 76% small-office/home, with reporting orgs clustered FR 40% / IT 35% / DE 13%). Read those volumes as a sample, not a worldwide Proxmox census. Dedicated-server and VPS fleets are under-counted there, not safe.
What to Do Now
1. Inventory the package
dpkg-query -W -f '${Version}\n' libpve-access-control
Anything below 8.0.4 is vulnerable. Run it on every node, not just the one you happened to SSH into.
2. Durable fix: upgrade off 7
There is no in-place vendor patch for PVE 7. The only durable fix is a supported 8.x or 9.x release with libpve-access-control >= 8.0.4. Plan the migration. Do not wait for a 7.4 security update that is not coming.
3. Immediate exposure cut: take :8006 off the internet
Bind or firewall the web UI/API to management networks or VPN only. That has been Proxmox's standing advice independent of this CVE. An unauthenticated login bug on a public :8006 is a hypervisor-root bug.
4. PVE 7 stop-gap (vendor-published, copy it from them)
IT-Connect points at a sed workaround on AccessControl.pm published in the Proxmox forum advisory thread (forum.proxmox.com thread 149331, post 867929, PSA-2026-00043-1). We are not reprinting that sed. Copy it from the advisory thread, apply it only as a stop-gap, then migrate. A one-line edit on an EOL Perl module is not a support story.
Treat any host still on 7 as potentially compromised until proven otherwise - especially if :8006 was ever reachable from the internet.
5. 2FA does not save default root
Enrolling TOTP on your personal @pve user while leaving root@pam without a second factor protects the wrong account. The skip path is exactly "user has no second factor."
After You Patched - Compromise Hunt
Patching (or migrating) closes the door. It does not tell you whether someone already walked through it.
Look for, without running anyone's exploit:
- Unexpected tickets or successful logins in auth /
pveproxylogs, especiallyPOST /api2/json/access/ticketthat do not match a real operator session. - New PAM users, new PVE users, new API tokens on
root@pam. - Unfamiliar VMs, templates, or snapshots you did not create.
- New listening services, unexpected systemd units, unexplained outbound connections.
- Ransomware notes, encrypted datastores, backup jobs disabled or pointed somewhere new.
- Cluster join events, new authorized_keys under
/etc/pve, or nodes you did not add.
If any of that is present, stop treating this as a patch ticket. Rebuild from known-clean backups; do not "clean in place" a hypervisor you no longer trust.
What We Don't Know
- Not in CISA KEV as of September 7, 2026. Watch the catalog. A KEV listing would change the default from "vulnerable" to "assume breach" for any still-exposed box.
- CrowdSec cannot confirm successes. Matching requests are attempts (and the public Nuclei template produces the same shape). Patched and firewalled hosts fail closed.
- Ransomware is reported, not CrowdSec-confirmed. Independent writeups (including swify.io) say PSA-2026-00043-1 followed reports of encrypted hosts. We are not restating that as CrowdSec fact.
- Sensor bias. CrowdSec coverage for this CVE is SOHO-heavy in FR/IT/DE. Hosting fleets may look quieter in that dataset than they are.
- No AppSec virtual patch from CrowdSec. The bypass request looks like a real 2FA login step; a WAF rule that blocks it would also block legitimate second-factor users. Network isolation of :8006 is the control that actually works.
- PVE 8.0.4+ / 9.x are not affected. Do not panic-patch a current 8/9 node for this CVE. Do still take :8006 off the internet.
Sources
- VulnCheck - "Proxmox VE 7.0-8.0 Authentication Bypass via tfa-challenge Parameter" (CVE-2023-54391 assigned 2026-09-01; CVSS 4.0 9.3; CWE-304)
- NVD - CVE-2023-54391 (CVSS 3.1 9.8; published 2026-09-01, last modified 2026-09-03)
- Proxmox - PSA-2026-00043-1, forum thread 149331 post 867929; pve-access-control commit 032e7d6d (libpve-access-control 8.0.4, 2023-07-20)
- CrowdSec - vulntracking report for CVE-2023-54391 (observation window 2026-09-04 to 2026-09-06; published ~2026-09-07): 1,210 signals, 133 unique IPs, peak 901 on Sep 4; not in CISA KEV as of 2026-09-07; in VulnCheck KEV; no AppSec virtual patch
- IT-Connect - "CVE-2023-54391: Proxmox Vulnerability Patched in 2023 Is Now Under Active Attack" (2026-09-08), including the pointer to the forum
sedstop-gap - swify.io - "Proxmox VE Authentication Bypass: What to Do Right Now" (2026-09-04): independent claim that PSA followed reports of encrypted hosts - hedged, not treated as CrowdSec confirmation