Proxmox CVE-2023-54391: Who Is Actually at Risk?

CVE-2023-54391 is a serious Proxmox VE authentication bypass. The "update Proxmox now" headlines leave out an important detail, though: plenty of Proxmox VE 7 and 8 installations are not vulnerable.

The affected package range is libpve-access-control >= 7.0-7 and < 8.0.4. That roughly corresponds to Proxmox VE 7.0 through 7.4 and the first Proxmox VE 8.0 release. The vulnerable code path was removed on July 20, 2023, long before the issue got a CVE number in September 2026. If your system has libpve-access-control 8.0.4 or newer, you don't need to panic about this particular vulnerability.

If you're still running Proxmox VE 7, it's more serious. The normal PVE 7 branch never got the fix, and the release has been out of support for a long time. If its management API has been reachable from untrusted networks, this is more than a routine patch reminder. End-of-life management software exposed to the internet is dangerous, even when the bug was fixed years ago in newer releases.

What does CVE-2023-54391 actually do?

CVE-2023-54391 lets an unauthenticated attacker bypass password verification for an enabled Proxmox user that has no second factor configured.

The issue is in the login flow handled by libpve-access-control. A normal Proxmox login sends credentials to the access-ticket API. When two-factor authentication is enabled, the server can return a challenge that has to be completed before the session is created.

The vulnerable logic accepted a request containing a tfa-challenge field without properly checking that the server had issued that challenge during a valid first authentication step. For an enabled account with no second factor, an attacker could skip password verification and get a valid session ticket. That includes high-value accounts such as root@pam if they're enabled and have no second factor configured.

VulnCheck rates the issue Critical at CVSS 9.3 under CVSS 4.0. The NVD-derived CVSS 3.1 score is 9.8. The attack works over the network, needs no prior authentication or user interaction, and can have high confidentiality, integrity, and availability impact. So the CVE deserves attention even though the vulnerable code is old.

Which Proxmox versions are actually vulnerable?

Go by package version, because the big Proxmox VE version number alone won't tell you. Proxmox's advisory defines the affected range as:

libpve-access-control >= 7.0-7 and < 8.0.4

The vulnerable range roughly corresponds to:

• Proxmox VE 7.0 through 7.4
• the initial Proxmox VE 8.0 release

The fix is present in:

libpve-access-control 8.0.4

That package shipped on July 20, 2023, which is why "PVE 8 is vulnerable" is too broad. A machine that installed ordinary PVE 8 updates after July 2023 has already moved past the vulnerable package. A PVE 8.1, 8.2, 8.3, 8.4, or Proxmox VE 9 system with normal updates is not affected by this CVE. Proxmox's own advisory states that no supported Proxmox VE release is affected.

As of September 2026, Proxmox VE 8 has itself reached end of support, and PVE 9 is the current supported major release. That leaves you with two separate questions:

1. Is this exact CVE present on the machine?
2. Is the machine still running a supported Proxmox release?

A late PVE 8 system can be safe from CVE-2023-54391 and still be on an EOL major release that no longer gets normal security support.

How can you check whether your host is affected?

Check the installed libpve-access-control package directly. A simple command is:

dpkg-query -W libpve-access-control

You're looking for a version older than 8.0.4 and at or above 7.0-7.

A more explicit check from the technical discussion was:

V=$(dpkg-query -W -f='${Version}' libpve-access-control 2>/dev/null)
echo "libpve-access-control: ${V:-not installed}"
dpkg --compare-versions "$V" lt 8.0.4   && echo ">>> AFFECTED"   || echo ">>> not affected"

Comparing the package version tells you more than whether the host says "PVE 8," since package versions and major releases don't map one to one.

If you're already on a supported Proxmox VE 9 system with current updates, you can set this CVE aside. If you find an old PVE 7 installation, running apt update && apt full-upgrade within the PVE 7 branch will not fix it.

Why can a fully updated PVE 7 host still be vulnerable?

Nobody knew the bug was a security vulnerability when the code was removed. The faulty logic went away during routine development in July 2023. Proxmox says the authentication bypass had not been found internally or reported at the time, so the change wasn't treated as a security fix. Security fixes get considered for backporting into older supported branches. An ordinary code rework usually doesn't, if nobody knows it closes a critical hole.

By the time CVE-2023-54391 was formally published on September 1, 2026, Proxmox VE 7 had been end of life for more than two years, and the normal PVE 7 package branch still contained the vulnerable logic. One of the vulnerability researchers later made exactly this point: a fully updated PVE 7 host can still be affected because the fix never went into the standard PVE 7 update path.

Proxmox published a hotfix for administrators who can't complete a major version upgrade right away, but the long-term answer is to get off PVE 7, and installing updates isn't enough for that. You have to take the supported upgrade path.

Was this really being exploited in September 2026?

CrowdSec saw traffic matching exploitation attempts, although that doesn't mean every matching request led to a successful compromise. Its September 7 report said 133 unique IP addresses had sent requests matching the CVE pattern since September 4, the day its detection rule went live. That's credible evidence of active scanning or exploitation attempts, and it doesn't mean 133 confirmed intrusions.

Once an exploit pattern is public, automated scanners sweep large address ranges looking for vulnerable systems. Most of what they hit may be patched, firewalled, nonexistent, or otherwise not exploitable. For an old host with port 8006 open to the internet, it's still serious, because a simple unauthenticated request is exactly what automated scanners pick up quickly.

Several administrators in the wider discussion also described suspicious compromises on old Proxmox systems, including changed passwords and hosts they believed had been breached. Unless someone forensically tied an incident to this CVE, those reports are anecdotes. Someone else's compromise story doesn't prove your system was breached, but if you were running a vulnerable, reachable host, it's a good reason to investigate.

Does two-factor authentication protect you?

It changes the conditions for the attack, but it's no substitute for upgrading.

The CVE description says the attacker can authenticate as an enabled user without a configured second factor. An account with a correctly configured second factor doesn't match the simplest vulnerable case in the advisory, which is useful defense in depth. It still doesn't make an EOL hypervisor safe.

A Proxmox host can have several enabled users, API tokens, service accounts, and administrative identities. If even one useful account lacks a second factor, the attacker may still have a way in. So the response needs several layers:

• upgrade or apply the vendor's emergency mitigation
• remove management access from untrusted networks
• require MFA for administrative users
• review unnecessary enabled accounts
• restrict API and GUI access with network policy

With those layers in place, a single mistake doesn't decide the outcome.

Should port 8006 ever be open to the public internet?

For almost every normal deployment, no. The Proxmox web UI and external API are served by pveproxy, usually on TCP port 8006. That interface can create, delete, start, stop, reconfigure, and open consoles on virtual machines and containers. It's a management plane, and treating it like an ordinary public web application lets attackers reach one of the most privileged services you have.

The strongest agreement in the discussion was about management network design more than about this specific CVE. A better pattern is to put Proxmox management interfaces on a dedicated management network or VLAN and restrict which systems can reach them. Remote administrators can come in through a VPN, a carefully maintained jump host, or another controlled access layer.

Reachability is what counts here. If a scanner on the internet can't connect to the management API, an unauthenticated API vulnerability is much harder to exploit remotely. You still have to patch, and segmentation just means an unknown vulnerability has to get past another boundary before it turns into an incident.

For more on the underlying platform and its network design, see the Mr.PlanB Proxmox hub.

Is a management VLAN enough?

No, because a VLAN on its own doesn't enforce anything. You need a management segment plus firewall rules that limit who can get into it.

Ordinary client devices, IoT systems, public-facing application VMs, guest Wi-Fi, and DMZ workloads have no reason to open connections to the Proxmox management interface. An administrative workstation or jump box may need access. A monitoring system might need carefully limited API access, and a backup or automation system might need a specific set of management endpoints. Deny everything else.

One administrator described their management segment as non-routed except through a controlled administrative path. Another said even internal user networks shouldn't automatically see management interfaces. Both approaches head the right way.

Don't assume the internet is hostile and the LAN is trustworthy. A compromised laptop, an exposed web application, an infected IoT device, or a stolen VPN credential can turn an internal network into an attack path. Apply least privilege between network zones as well as between user accounts.

What should you do if an affected host was internet-facing?

Treat it as a possible incident and more than a late patch job. First, restrict access. If you can, cut public access to port 8006 immediately with a firewall, upstream ACL, VPN-only policy, or management network, so untrusted networks can no longer reach the host directly.

Then upgrade to a supported Proxmox release, or follow the vendor advisory if change control rules out an immediate major upgrade. After that, investigate: review enabled users and authentication configuration. Look for unexpected users, changed passwords, API tokens, SSH authorized keys, and unexplained configuration changes. Go through Proxmox task history and system logs for administrative actions you don't recognize, and inspect firewall rules, storage definitions, VM configuration, backup settings, and scheduled jobs.

Rotate any credentials that could have been exposed. If the host held secrets that guests or external systems also trusted, consider rotating those as well. If you think a real compromise may have happened, preserve logs before cleaning up the machine.

With an authentication bypass, a successful attacker can look like a logged-in administrator after the first request. Not seeing failed login attempts tells you very little, and if the host was vulnerable and reachable, the lack of an obvious alert doesn't prove nothing happened.

A Proxmox Health Check can help find configuration weaknesses, but a suspected compromise calls for incident response, and a configuration review alone won't cover it.

Was the original "UPDATE PROXMOX NOW" warning too alarmist?

The urgency was justified for some people, but leaving out the version details changed what the warning meant. The vulnerability is severe. An unauthenticated attacker potentially becoming root@pam without knowing the password is a big deal, and CrowdSec seeing exploit-pattern traffic shortly after disclosure deserves attention too.

Still, an administrator on current PVE 9 or a properly updated later PVE 8 install shouldn't read the headline and think their host just picked up a three-year-old authentication bypass.

A better version of the warning would be: if you run PVE 7, or an initial PVE 8.0 system with libpve-access-control below 8.0.4, check it now. If that host was reachable from untrusted networks, investigate it for compromise. If you run a current supported PVE release, this CVE is already behind you. That version is less dramatic and a lot easier to act on.

Management-plane exposure matters more than this one CVE

CVE-2023-54391 is unusual because it became public years after the affected code was gone from newer Proxmox versions. Some administrators upgraded long ago and removed a critical authentication bypass without knowing it. Others stayed on PVE 7 and stayed exposed, also without knowing.

Nobody should install every update the minute it appears, since infrastructure changes need testing. Putting off major upgrades indefinitely does cost you in security, though, and exposing the management plane makes that cost much bigger.

Keep Proxmox on a supported release, keep the management interface off the public internet, use MFA, and segment management traffic. Before reacting to a vulnerability headline, find out the exact package version you're running.

If an unsupported hypervisor is still running because "it has worked fine for years," keep in mind that this CVE sat in old systems for years before anyone knew about it, including the people who decided not to upgrade.