Proxmox Vulnerability: What to Do About CVE-2023-54391

CVE-2023-54391 is a critical authentication bypass in Proxmox Virtual Environment that lets an attacker log into the web console as root, with no password and no second factor, using a single crafted login request, and it is being exploited right now. If you run Proxmox to host your virtual machines, today’s job is a version check, an upgrade off any end-of-life 7.x build, and a look at whether your management port is reachable from the internet. This note is the plain-English version of those steps, written for the person who just saw the advisory and needs to know what to do.

Proxmox published advisory PSA-2026-00043-1 on September 1, 2026, after receiving numerous independent reports of the bug within a two-day window, several of which also reported exploitation in the wild. A public proof of concept is circulating, and users on the Proxmox support forum and LowEndTalk are already reporting compromised boxes, including servers hosted on OVH. securityonline.info and TheHackerWire have technical write-ups up; as of this writing, the larger security outlets have not covered it yet, so this is still early.

What’s actually broken

Proxmox’s web console has a login flow for accounts that use two-factor authentication: you enter a password, then a tfa-challenge value for the second-factor code. In affected versions, the server-side code that handles that second step has a gap: when a tfa-challenge value is present in the login request, it skips checking the password entirely, and it never validates that the value itself is real. It does not even confirm the account has a second factor configured in the first place.

The practical result is that anyone who sends a login request with any tfa-challenge value attached gets treated as if they had already passed both checks. Send that request for the root@pam account, the default administrator, and you are in. No valid password, no valid code, one HTTP request.

That is CWE-304, a missing critical step in authentication, and it carries a CVSS score of 9.8, about as high as scores go. The fix itself shipped quietly in July 2023, inside a routine refactor of the access-control code (libpve-access-control 8.0.4). It was not flagged as a security fix at the time, which is the reason a 2023-dated CVE only became a live advisory this week: nobody realized what that refactor had actually closed until independent researchers found the gap in older builds still running it.

Who this affects

Proxmox VE 7.0 through 7.4, and the initial Proxmox VE 8.0 release, running libpve-access-control versions from 7.0-7 up to just before 8.0.4. All of the 7.x line has been end of life since July 2024. If you are on a current 8.x or 9.x release, you already have the fix. If you are not certain which line you are on, that is itself worth finding out today.

Proxmox is a real alternative to VMware for hosting virtual machines and containers, and it shows up everywhere from home labs that quietly became production servers to budget-conscious small businesses and MSPs to dev and CI infrastructure. Running Proxmox is not the finding here. Still running an end-of-life 7.x build, two years past its last security update, with an administrator account that has no second factor and a management console open to the internet, is the finding.

A hypervisor is worth taking more seriously than a typical server, because it is not one machine. It is the machine underneath every virtual machine and container a business runs. Root on the Proxmox host means root on all of them, plus the ability to read every disk image sitting on that host at rest. A compromised print server or web app is bad. A compromised hypervisor is the whole rack.

What to do today

Whoever already manages your virtualization can run through these in a few minutes.

1. Check your version. In the Proxmox web UI, look at Node summary, or run pveversion at the command line. You want the Proxmox VE version and the libpve-access-control package version specifically.

2. Upgrade off anything before 8.0.4. For a current 8.x or 9.x install that is simply behind on patches, this is a normal package update. For any 7.x install, there is no backport, since that line is end of life: the real fix is an upgrade path to a supported 8.x or 9.x release. Treat that as the priority even though it is more work than a quick patch.

3. Turn on a second factor for every privileged account today, as an immediate stop-gap. This specific bypass only works against accounts with no second factor configured. TOTP or WebAuthn on root@pam and any other administrator closes the door this particular flaw uses, even before you finish the version upgrade.

4. Get the management port off the open internet. Proxmox’s web console and API listen on port 8006. It does not need to be reachable from anywhere in the world; restrict it to a management VPN or a short list of trusted addresses. If you cannot upgrade immediately, this step matters even more.

5. If the console was internet-facing and unpatched, look for signs someone already got in. Check /var/log/pveproxy/access.log for login requests carrying a tfa-challenge parameter you do not recognize, review the audit log for account or permission changes you did not make, and look at what is running on any guest VM you did not start. If you find something, treat it as a hypervisor-level incident, not a single-VM cleanup.

How you’d know if you were exposed

An external penetration test is the independent version of the checks above: from outside your network, a tester looks at what actually answers on the internet, and whether it is patched, configured, and reachable only by the people who should reach it. A Proxmox management console with an out-of-date libpve-access-control package and no restriction on who can reach port 8006 is exactly the kind of finding that test surfaces.

Because Proxmox often sits inside the trusted internal network rather than facing the internet directly, an internal penetration test matters here too. A hypervisor compromised from an already-breached internal host is still a full loss of every VM it runs, even if the management port was never public.

That is a periodic check. Between annual tests, this is the kind of thing continuous monitoring is built to catch as soon as it appears on your footprint, which is what Blindsight is for. External testing at azpentest starts at $4,000, retest included; the published tiers are on pricing.

Frequently asked questions

Is running Proxmox on the internet a security problem?

No. Self-hosting your own virtualization platform is normal, sensible infrastructure. The issue is not that Proxmox exists, it is running an end-of-life 7.x build with the web console reachable from the internet and no second factor on privileged accounts. Fix those three things and this specific bypass does not work against you.

I already have two-factor authentication turned on. Am I safe from this one?

From this specific bypass, yes. CVE-2023-54391 only lets an attacker skip straight past the login for accounts that have no second factor configured. An account with TOTP or WebAuthn enabled still gets checked properly. You should still get off end-of-life 7.x, since it receives no further security fixes at all.

We’re a small business running one Proxmox box. Would attackers really bother?

They do not pick targets by name. A bypass this simple, a single crafted login request, gets swept up by automated internet-wide scanning within days of going public. Small offices and home-lab-turned-production servers get hit because they run the software and answer on port 8006, not because anyone targeted them specifically.

How do I find out if our Proxmox server is exposed?

Check your Proxmox VE version and the installed libpve-access-control package version, either in the web UI or with pveversion at the command line. If you are on anything older than 8.0.4, or on any 7.x build at all, and the management port (8006) answers from outside your network, you are exposed. An external penetration test is the independent version of that same check.

Patch this Proxmox vulnerability, then decide what you want to know next

CVE-2023-54391 is being exploited against end-of-life Proxmox VE 7.x installs right now. The work for today is a version check, a second factor on every privileged account, port 8006 off the open internet, and an upgrade path off 7.x. For the source material, start with Proxmox’s advisory thread, securityonline.info’s write-up, and the NVD record.

Not sure whether your hypervisor is on a patched build, or whether that management console answers from outside your office? Tell us what you run and we will take a look, then come back with a fair, fixed quote if an external test is the right next step. Request a quote.