PSA-2026-00043-1 and CVE-2023-54391 both landed on September 1, 2026, describing an unauthenticated login bypass in end-of-life Proxmox VE 7 that the vendor says a July 2023 refactor closed by accident — before anyone knew it was there.
What happened
On Tuesday, September 1, 2026, Proxmox posted security advisory PSA-2026-00043-1, titled “Authentication bypass in EOL Proxmox VE 7 release,” to its security advisories forum. Roughly fourteen hours later, at 10:17 p.m. UTC, a matching record appeared in the National Vulnerability Database. Its identifier is CVE-2023-54391 — a 2023 number, published in September 2026.
The NVD description reads: “Proxmox Virtual Environment (VE) 7.0 through 8.0 contains an authentication bypass vulnerability in libpve-access-control before 8.0.4 that allows unauthenticated attackers to authenticate as any existing enabled user without a configured second factor by supplying an arbitrary tfa-challenge value in the API login endpoint.”
The mechanism is worth reading twice. An attacker who can reach the management interface — port 8006 by default — sends a login request carrying a tfa-challenge value of their own choosing. The access-control layer accepts it as proof that the account already cleared its first authentication step, and issues a session. No password is involved. The accounts it works against are the ones with no second factor configured, which on most installations means all of them.
The record is scored CVSS v3.1 9.8 and CVSS v4.0 9.3, both by [email protected]. VulnCheck assigned the identifier as a third-party CNA. The weakness is CWE-304, a missing critical step in authentication. Affected package versions run from libpve-access-control 7.0-7 up to but not including 8.0.4. In product terms, Proxmox’s advisory puts the impact on “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),” and states flatly that “No supported Proxmox VE release is affected.”
What makes this more than a late CVE for a dead release is the timeline Proxmox published alongside it. The vulnerable code path, the advisory says, was closed in July 2023 — and then it explains why nobody heard about it: “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.”
A rewrite of the two-factor handling closed an unauthenticated login bypass three years ago, and its authors did not know that was what they had done.
Why it matters
Every mechanism that tells an administrator to patch is downstream of somebody knowing there is something to patch. The changelog entry, the advisory, the CVE record, the scanner signature, the KEV listing, the compliance clock — all of it starts with a human recognizing a defect as a security defect. When a refactor closes a hole nobody has found, that chain never starts. The fix ships. It works. And it reaches only the operators who happened to upgrade for unrelated reasons.
That is a limit on what patch-notification systems can do, not a criticism of Proxmox, which documented the sequence honestly the moment it had reason to look. The population still exposed today is exactly the population that stopped upgrading — and what would have saved them was an upgrade whose security value was invisible to everyone, the vendor included, at the time it shipped.
The identifier itself carries a second problem. CVE-2023-54391 will sort as a 2023 vulnerability in every tool that reads the year out of the ID, forever. Triage rules of the form “anything from the last two years” will drop it. Dashboards ordered by CVE year will bury it below records from 2024 and 2025 that matter far less. The year in a CVE ID has never meant “the year the world found out,” and this record is an unusually clean demonstration of the gap: assigned in 2026, numbered 2023, describing code fixed in 2023 for reasons that had nothing to do with security. Two variants of the same mismatch ran here last week: AjaxPro’s CVE-2021-23758, fixed in November 2021 and put on a federal clock this year, and libuser’s CVE-2015-3246, an eleven-year-old record with a live deadline.
End-of-life status usually means no vendor path to a patch. This case is stranger, because the fix already existed: it shipped in libpve-access-control 8.0.4 in July 2023, a year before VE 7 went end of life. Operators who upgraded were covered by a fix nobody labeled. Operators who stayed were exposed by a bug nobody had named. The remedy today is not a patch at all but a major-version migration — a substantially larger ask than “apply the update.”
Then there is the exploitation question, which is where the sourcing gets thin and where this page will not pretend otherwise. A Proxmox forum thread opened on August 31, 2026 under the title “Proxmox VE 7 is vulnerable to some type of 0day/RCE non auth.” Multiple posters described hosts encrypted by ransomware, one writing that “they encrypted the LVM unit located at /var/lib/vz,” another that “Everything happened on the same day at the same time.” A post circulated on Reddit’s r/netsec claimed that “A lot of proxmox 7.0-7 and < 8.0.4 has been rooted today, it’s needed to have port :8006 open.”
Three things cut against those reports. The versions do not line up: posters named VE 7.x but also 8.0.x through 8.4.0, and the advisory says releases after the initial 8.0 are not affected — so either some intrusions came in another way, or the reported versions are wrong. Longtime forum members observed that the accounts reporting compromise had all registered recently. And a moderator dismissed the framing: “Systems without current system updates can be hacked, nothing is new or urgent on this.” Proxmox has not confirmed exploitation in the wild, and this page does not assert it.
One independent data point does corroborate that somebody has a working request pattern. Emerging Threats shipped ruleset v11271 on September 1, 2026 containing SID 2071872, “ET WEB_SPECIFIC_APPS Proxmox VE 7.x Authentication Bypass (PSA-2026-00043-1).” A detection vendor does not write and name a signature against a specific PSA without having seen the traffic it is meant to catch. That is evidence of a reproducible exploit, not of victims.
Finally: this is not on a federal clock. The NVD record carries no cisaExploitAdd, no cisaActionDue, and no cisaRequiredAction. Nothing was added to the KEV catalog on September 1 or September 2. Federal civilian agencies have no BOD 26-04 deadline for this, and the last KEV additions remain the two PaperCut records from August 31.
What to do
Establish what you are running. The package, not the product banner, is what determines exposure: dpkg -l libpve-access-control. Any version at or above 7.0-7 and below 8.0.4 is vulnerable. That maps to Proxmox VE 7.0 through 7.4 and the initial 8.0 release.
Take the management interface off the internet today. This is the mitigation that actually holds, and it holds regardless of how the exploitation reports resolve. The bypass is a network-reachable, unauthenticated request to the API login endpoint on port 8006. Proxmox has never recommended exposing that interface publicly. Put it behind a VPN or on a management VLAN before you plan anything else.
Understand the second-factor detail before you rely on it. The CVE record is explicit that the bypass authenticates “as any existing enabled user without a configured second factor.” By the record’s own wording, accounts that do have TFA enrolled are not reachable this way. That is a real interim control on an end-of-life host you cannot migrate this week — but it comes from the record’s description rather than from independent testing, and it should not substitute for getting 8006 off the public internet.
Then migrate. There is no patch for VE 7.x, because VE 7.x is end of life. The supported path is 7.x to 8.x and then forward to a current release. Treat that as the remediation, not as a subsequent project.
Look for evidence rather than assuming its absence. Review /var/log/pveproxy/access.log for successful authentications not preceded by a normal credential exchange, particularly against the @pam and @pve realms, and check for accounts, API tokens, and SSH keys you did not create. If you find a compromised host, snapshot it before rebuilding — the forensic record on this flaw is thin enough that a real capture is worth more than another rebuild.
Sourcing note
Checked: Proxmox security advisory PSA-2026-00043-1, dated September 1, 2026, as posted to the Proxmox security advisories forum by the ProxmoxSecurityAdvisory account; the NVD record for CVE-2023-54391 (published September 1, 2026 at 10:17 p.m. UTC, CVSS v3.1 9.8 and v4.0 9.3, both scored by VulnCheck, CWE-304), which carries no CISA KEV fields; the Emerging Threats ruleset v11271 summary for September 1, 2026, listing SID 2071872; and the Proxmox support forum thread opened August 31, 2026.
Unresolved: Proxmox has not confirmed exploitation in the wild, and this page treats the forum and Reddit reports as unverified user claims. The version ranges in those reports (up to 8.4.0) conflict with the advisory’s stated scope (7.0 through 7.4 and the initial 8.0), and that conflict is not resolved by any public source. The identity of the reporter who prompted the advisory is not stated in the material reviewed. The claim that enabling a second factor blocks the bypass rests on the CVE description’s wording and has not been independently tested here.
Not the same flaw: CVE-2023-43320, a Proxmox two-factor bypass published in September 2023 and scored 8.8, requires an authenticated attacker and covers a different product range. It is easily confused with this record and is not it.
CISA’s pages return 403 to automated fetching, so KEV state was checked through the NVD record’s CISA fields and a third-party mirror rather than cisa.gov directly.