Proxmox VE 7 authentication bypass (CVE-2023-54391)

An authentication bypass, put back in context

In late August 2026, several administrators report encrypted hosts and wiped logs on the Proxmox forum, under a blunt title: "Proxmox VE 7 is vulnerable to some type of 0day/RCE non auth". The discussion wavers. Some call it a 0day, others blame an old Linux kernel left unpatched. Both readings are incomplete, and the reality can be documented in a handful of facts, which this article sets in order.

On 1 September 2026 Proxmox published advisory PSA-2026-00043-1: an authentication bypass in the end-of-life releases of Proxmox VE 7. An attacker who can reach the management interface can log in as root@pam, the superuser, without supplying a password. On a hypervisor, gaining root on the host amounts to taking control of every virtual machine and every container it runs. The "non auth RCE" label from the title is not strictly accurate, but its consequence is: a stranger on the Internet and a single request are enough to run code as root on the machine that runs your entire infrastructure.

This article takes the flaw apart mechanism by mechanism, explains why it resurfaces three years after it was fixed, gives you what you need to check whether you are exposed, and details the remediation, from the emergency move to a full rebuild if you have already been hit.

The facts, as the advisory lays them out

Scope before mechanism. Here is what is established, and what is not.

Two clarifications that change how you read this. First, no currently supported release is affected: up-to-date Proxmox VE 8.x and 9.x have carried the fix for a long time. Second, on the CVE itself, the messaging was muddled: some early coverage said no number had been assigned yet and that the reporter was about to submit it to MITRE, while vulnerability databases now reference it as CVE-2023-54391. We use that identifier, with a caveat: on a case this fresh, a renumbering is not out of the question.

The flaw, line by line

To see what breaks, you first have to see how a two-factor login is supposed to work in Proxmox.

When you log in, the client sends a POST to /api2/json/access/ticket with your username, your authentication domain (the realm: pam, pve, LDAP, and so on) and your password. If the account has no second factor, the server validates the password and returns an authentication ticket directly, the signed cookie that then authorizes every API call. If the account has a second factor, the server does not hand over the final ticket right away: it returns an intermediate challenge ticket, and the client has to replay a second POST to the same endpoint, this time with the tfa-challenge parameter carrying that intermediate ticket together with the second-factor response (the TOTP code, the WebAuthn assertion, and so on). The server checks that challenge, and only then issues the full ticket.

The whole problem lies in how the code decides whether it is at the first or the second step. On vulnerable versions, that decision rests on the mere presence of the tfa-challenge parameter. As soon as it appears, the code assumes it is at the second-factor verification step, and it skips password verification: the user is presumed to have already proven their password on the previous round. The trouble is that this intermediate ticket, which was meant to guarantee the first round actually happened, is not validated for an account that has no second factor. The code tries to check a 2FA response for a user who has no 2FA, finds nothing to verify, and instead of rejecting the request, it lets it through.

In other words, the guard that was supposed to ask "is this challenge legitimate?" settles, for an account with no second factor, for "there is a tfa-challenge parameter, so this is step 2, all good". The value of that parameter can be anything. The password is never asked for. The full ticket is issued.

The request then comes down to this, and it is what it does not contain that matters:

POST /api2/json/access/ticket HTTP/1.1
Host: target:8006
Content-Type: application/x-www-form-urlencoded
 
username=root@pam&tfa-challenge=<arbitrary value>

Note what is missing: the password field. That is where the bypass happens. The reporter, Nebu Security, published the mechanism and a PoC, but chose not to release the exact value that triggers the pass-through, to slow down copy-paste exploitation. We take the same stance: the shape above is enough to understand the flaw and to spot it in your logs, without turning it into a ready-made weapon. The nuance changes little for the attackers already at work; it matters for the reader discovering the topic.

From root@pam to code execution

A ticket for root@pam is not "read access to the dashboard". root@pam is the account bound to the real Unix root of the host, and the Proxmox API is, by design, a full remote control of the machine. From that ticket, code execution is not a second vulnerability to find, it is a feature:

• The host console. The interface exposes a root shell on the node via termproxy and a WebSocket (vncwebsocket), the very "Node > Shell" you use every day in the UI. With a root ticket, that is a root terminal on the hypervisor.
• Execution inside guests. On any VM that runs the guest agent, the qemu-guest-agent call runs commands inside the virtual machine. Root on the host becomes root in the guests.
• Backup and hook scripts. Attaching a script triggered on VM start or on backup plants persistent code execution that survives a simple reboot.

That is why the forum thread calls it "non auth RCE": between the anonymous request and code running as root, there is no intermediate wall to climb. The flaw does not run code by itself, but it hands the keys to someone whose job that then is.

"0day"? A 2023 fix, a 2026 exploitation

This is the point the forum thread could not settle, and it is the most interesting one for a defender.

A 0day, strictly speaking, is a flaw exploited before a fix exists. That is not the case here. The bug was fixed in July 2023, in libpve-access-control 8.0.4, around the release of Proxmox VE 8.0. What stands out is the way it was fixed: quietly, with no CVE and no advisory, a correction folded into a stream of ordinary updates. For two years, the flaw stayed patched for anyone who kept up with updates, and wide open for anyone who did not.

And that population is large. Proxmox VE 7.x has been end of life since July 2024: no more fixes, no more support, but a sizeable installed base, because a hypervisor that "works" rarely gets replaced for comfort. In late August 2026, an actor found, analysed and replayed that old silent fix, turned it into an attack method, and set it loose on that base. So this is not a 0day, it is an n-day: an old flaw, known to the source code for a long time, weaponized against machines that stopped receiving fixes. For you, the distinction is crucial, because it names the real risk: it is not your up-to-date servers that are targeted, it is your forgotten hypervisors, the ones nobody remembers are still running.

There is a lesson here that shows up at every incident of this kind: a fix shipped without a security label protects less well than a fix that is announced. Whoever applies updates is covered without knowing it; whoever decides, in the absence of an announcement, that "nothing is urgent this month", stays vulnerable while believing the opposite. The silence of 2023 is part of the story of 2026.

Who is affected, exactly

The dividing line is sharp, which makes triage fast.

Two conditions must both hold for an attacker to profit, and each is a chance to protect yourself:

1. The management interface must be reachable. The API and UI live on port 8006. A host whose port is only reachable from an administration network or a VPN offers no surface to the anonymous attacker on the Internet.
2. The target account must have no second factor. The bypass only works for an account without 2FA. And root@pam has none by default. Conversely, an account protected by a TOTP or a WebAuthn key is not bypassable through this flaw: the code finds a real second factor to check, and it checks it.

That second point matters because it turns a routine hygiene measure, enabling 2FA on admin accounts, into a direct countermeasure against this specific vulnerability.

What attackers do once inside

The ongoing exploitation is not the work of a single actor. At least two profiles share the base: one deploys ransomware (storage encryption, ransom note), the other installs cryptominers that quietly monetize the hypervisor's CPU. Both share a particular care in wiping their tracks, and it is those anti-forensic moves that give the best indicators of compromise.

The observed and reported behaviors:

• A root shell opened with no prior authentication in the logs, just before those logs are tampered with.
• Logs redirected to /dev/null: log files are replaced with symbolic links to /dev/null, so that everything written afterwards vanishes silently. A log file that has become a symlink is a strong signal.
• Destruction of /var/lib/dpkg/status: that file holds the inventory of installed packages. Deleting it breaks the package manager's knowledge base, hinders post-incident analysis, and blurs any attempt to know what was changed.
• Deletion of existing logs: in the initial forum case, all logs had been erased, leaving only a suspicious IP address in the last lines.

The archetypal scenario told on the forum has every ingredient: a host end of life for two years, a firewall disabled during a trip, VMs well protected behind a CDN but the host itself exposed, a single root account with a thirty-character password. The long password was worth nothing: the flaw does not ask for it.

Am I vulnerable? How to check

Three questions, in order: is my version affected, is my interface exposed, have I already been visited.

1. Package version. This is the arbiter, more reliable than the version number shown in the UI. On the host:

# Exact version of the faulty package
dpkg -l libpve-access-control | grep '^ii'
 
# Overview
pveversion -v | grep -E 'pve-manager|libpve-access-control'

If libpve-access-control is below 8.0.4, the host is vulnerable. In practice, any installation still on Proxmox VE 7.x is.

2. Interface exposure. From a machine outside your administration network, check whether port 8006 answers. If it answers from the Internet, that is an emergency in its own right, independent of the version:

# Is the management port answering where it should not?
curl -sk -o /dev/null -w '%{http_code}\n' https://your-host:8006/

3. Traces of exploitation. The login endpoint is logged by pveproxy. Look for POSTs on the ticket, in particular those that end in a root@pam session from an unknown address:

# API login attempts, to cross-check against legitimate IPs
grep 'POST /api2/json/access/ticket' /var/log/pveproxy/access.log*
 
# Anti-forensic indicator: a log file turned into a symlink
find /var/log -maxdepth 3 -type l -ls
 
# Consistency of the package inventory (missing or truncated = suspicious)
ls -l /var/lib/dpkg/status

Round it out with the usual checks after a suspected host compromise: crontab -l and /etc/cron.*, unknown CPU-hungry processes (top, a miner does not hide well), SSH keys added to /root/.ssh/authorized_keys, VMs or containers you do not recognize. One unpleasant point: if the attacker did their job, the logs are already gone. So the absence of a trace is not proof of innocence on an exposed, vulnerable host.

On the public offensive-tooling side, the picture as we write is clear: no Metasploit module and no dedicated ExploitDB entry for CVE-2023-54391 (searchsploit proxmox only turns up old unrelated tickets and a TOTP brute-force). What is circulating is a standalone PoC, which is not reassuring for all that: an authentication bypass of this kind is rewritten in a few lines once the principle is understood.

What to do now

From most urgent to most durable. The first two moves take a few minutes and close the immediate window; the rest fix the underlying problem.

• Take the 8006 interface off the Internet, right now. This is the move that cuts the attack, whatever your version. A hypervisor's management plane has no business being directly reachable on the Internet: behind a VPN, a bastion or a firewall allowlist, never in the front line. If you were to do only one thing, this is it.
• Enable a second factor on root@pam and on every admin account. Again, an account with 2FA is not bypassable through this flaw. This is a direct countermeasure, not just a general good practice.
• Apply the fix. On a supported branch, updating is enough: libpve-access-control 8.0.4 or later carries the fix. Proxmox has also made available a stop-gap patch that validates the challenge ticket properly, for environments that cannot migrate within the hour.
• Migrate off Proxmox VE 7.x. This is the only durable answer. 7.x has not been maintained since July 2024: this flaw is only a symptom, and the next n-day will find the same machine just as defenceless. The target is a supported branch, Proxmox VE 8.4.x or 9.x. On an end-of-life host you do not bodge in a package from another major branch, you plan a clean version upgrade.
• If compromise is confirmed, do not clean, rebuild. A host on which a stranger had root can no longer be trusted: ransomware or miner, you do not know what remains. Isolate the machine from the network, preserve what can be preserved for analysis, restore guests from backups predating the intrusion and verified, reinstall the host from scratch, then rotate every secret that may have passed through it: passwords, API keys, tokens, SSH keys, guest credentials.

A wider lesson: the management plane does not go on the Internet

Let us step back from the Proxmox case for a moment, because it illustrates a pattern we deal with in audit after audit.

An administration console exposed on the Internet is a time bomb, whatever its brand. vSphere, a motherboard IPMI, a hypervisor, a storage controller, a management panel: these are very high value surfaces, where the slightest authentication flaw gives, not a foot in the door, but the whole house. The management plane belongs on a separate administration network, reachable by VPN or bastion, full stop. Here the flaw requires two conditions, and the exposure of port 8006 is the one the organization controls entirely, whereas it has no say over the existence of the bug.

The right question, after an alert like this, is not only "am I up to date?", it is "what, on my side, is reachable from the Internet without my having decided it?". A forgotten hypervisor, an admin interface left in the front line "for the duration of a fix", a test service that was never cleaned up. That is exactly what an external attack-surface inventory reveals, and what a well-targeted vulnerability scan cross-checks against known vulnerable versions, provided your information-system map actually contains those machines. Today's flaw is fixed with one command; the blind spot that left it reachable takes a method.

Not to be confused with: CVE-2026-51083

Because the two are circulating at the same time and search engines mix them up, a point of order. CVE-2026-51083 is a separate, far less severe vulnerability. It affects the qemu-server package on the supported 8.x and 9.x branches, via the cloudinit/dump endpoint that exposed password hashes from the cloud-init configuration to already authenticated users with limited rights (broken access control, CWE-284, CVSS 6.5). It is fixed in qemu-server 8.4.8 and 9.1.8. Nothing to do with the tfa-challenge authentication bypass: this one requires an account, does not grant root, and concerns up-to-date versions. If you keep up with updates, you have already closed it.

Frequently asked questions

Is it really a 0day?

No, strictly speaking. The flaw was fixed in July 2023 in libpve-access-control 8.0.4, but with no CVE or advisory at the time. It resurfaces in 2026 because it is now mass-exploited on end-of-life installations that never received that fix. It is an n-day, not a 0day. The distinction is not cosmetic: it says your up-to-date machines are safe and the danger is concentrated on forgotten hosts.

Which Proxmox VE versions are affected?

Proxmox VE 7.0 to 7.4 (end of life since July 2024) and the very first build of 8.0, i.e. libpve-access-control before 8.0.4. Any 8.x kept up to date and any 9.x are fixed.

How do I know if I am hit?

On the host, dpkg -l libpve-access-control. If the version is below 8.0.4, you are vulnerable. Also check that port 8006 is not reachable from the Internet.

I enabled 2FA on root, am I protected?

Against this specific flaw, yes. The bypass only works for accounts without a second factor. An account protected by a TOTP or a WebAuthn key is not bypassable this way. That is no reason to stay on 7.x: other flaws will not be so lenient.

Does my root account's long password protect me?

No. The flaw does not test the password, it skips that check. A hundred-character password is as useless as an empty one against this bypass.

How do you get from access to code execution?

A root@pam ticket gives full control of the API, which includes opening a root shell on the host (node console), running commands inside guests via the guest agent, and attaching persistent scripts. Code execution is not a second flaw, it is an API feature now driven by an attacker.

Is there a public exploit?

A standalone PoC is circulating, published by the reporter (Nebu Security), who chose not to release the exact value of the triggering parameter. There is, at this stage, no Metasploit module and no dedicated ExploitDB entry. That does not reduce the risk by much: the principle is simple to reimplement.

My host was encrypted or is mining crypto, what do I do?

Treat the host as permanently compromised. Isolate it, restore guests from backups predating the intrusion and verified, reinstall the machine from scratch, and rotate every secret that may have passed through it. Do not settle for removing the visible payload: root access rarely leaves a single door.

CVE-2026-51083, is that the same thing?

No. It is a distinct vulnerability, a disclosure of cloud-init password hashes in qemu-server on the supported versions, fixed in 8.4.8 and 9.1.8, which requires an authenticated account and does not grant root. Up to date, you are covered.

Conclusion

This Proxmox flaw is no technical feat: it is a badly placed authentication guard, fixed two years ago, that today catches everyone who left an end-of-life hypervisor running on the Internet. The lesson is not "Proxmox is dangerous", it is as dangerous as any software you stop updating. The lesson is that the management plane of a virtualization infrastructure has no business in the front line, that a second factor on admin accounts often turns a critical flaw into a non-event, and that a machine you forgot to keep track of ends up being tracked by someone else.

The emergency move fits in one sentence: get port 8006 off the Internet, turn on 2FA, plan the exit from 7.x. The rest is a matter of method.

Have Flawfence analyse your exposure: we map what, from the Internet, answers in your name, hypervisors and admin interfaces included, and we tell you what to close first.

Sources

• Proxmox Support Forum, "Proxmox VE 7 is vulnerable to some type of 0day/RCE non auth"
• securityonline.info, "Proxmox VE 7 Auth Bypass: PoC Public, Exploited in the Wild"
• IONIX Threat Center, "CVE-2023-54391: Authentication Bypass / RCE Precursor, Proxmox VE 7.0 to 8.0"
• OffSeq Threat Radar, "Authentication bypass in EOL Proxmox VE 7 release"
• Undercode Testing, "The Zombies In Your Server Room: Hunting End-of-Life Proxmox VE Instances"
• LowEndTalk, "PSA: Update your Proxmox VE installations (Authentication bypass in EOL Proxmox VE releases)"
• SentinelOne, CVE-2026-51083 entry (separate vulnerability, qemu-server)
• Proxmox VE, official security advisories page