Proxmox VE 7: Attackers Log In as Root Without a Password

In brief

Proxmox has been warning since September 1, 2026: in Proxmox VE 7 and in very early 8.x installations, login can be bypassed entirely — no password, straight in as root.
The flaw is being actively exploited. Affected users report encrypted systems with ransom demands, and cryptominers planted on their hosts.
Prepaid-Host is not affected. If you run Proxmox yourself — including on a server with us — check your package version now.

What happened

On September 1, 2026, Proxmox published advisory PSA-2026-00043-1. The trigger wasn't internal testing but cries for help. Proxmox itself writes that it only learned of the problem through “many independent reports within the last two days, which also report exploitation in the wild". In other words: the flaw became known because break-ins had already happened.

It started in the Proxmox forum on August 31. A user reported that their Proxmox VE 7 installation had been encrypted and a ransom was being demanded for decryption. All logs had been wiped. Within a day, more affected users came forward with the same picture. The vulnerability still has no CVE number as of today.

The bug: a parameter that skipped the password check

Login to the Proxmox API goes through POST /api2/json/access/ticket. This call accepts a parameter tfa-challenge for the second factor. For accounts without a second factor configured, this parameter was never checked — and, crucially, its mere presence caused the check of the submitted password to be skipped entirely.

In practice, that means: anyone who sends the parameter with any value at all logs in as any activated user without two-factor enabled. By default, that includes root@pam. No password, no trial and error, no guessing. One affected user describes in the forum how the attacker “straight away opened up a root Shell with no seemingly prior auth".

The only prerequisite is access to the web interface, or rather the API, on port 8006. Anyone who exposes that port to the open internet is vulnerable.

Open for three years — and the fix was an accident

The affected package is libpve-access-control, from version 7.0-7 up to but not including 8.0.4. Version 8.0.4 was released on July 20, 2023, and fixed the problem. Nobody knew that, though.

The fix was a side effect of a rework of the two-factor login. Nobody recognized it as a security fix — so there was no advisory and no backport to the Proxmox VE 7 branch, which was still maintained at the time. The flaw stayed open there while it had long since been closed in newer versions. For over three years, until attackers found it.

That's the real lesson from this incident. A version without security support isn't “old but stable." It's a version whose flaws someone else will eventually find — and not report. Proxmox VE 7 has been end-of-life since July 2024.

Are you affected? Here's how to check

On the Proxmox host, one command is enough:

dpkg-query -W -f '${Version}\n' libpve-access-control

If the version returned is 7.0-7 or higher but below 8.0.4, the system is vulnerable. pveversion -v gives you a full overview of all package versions.

How to spot a breach

Reports from affected users point to concrete indicators. At least two groups appear to be active: one using encryption and ransom demands, one deploying a cryptominer. What to look for:

A file /var/lib/systemd/PVE-1 — that was the miner.
A service PVE-1.service in the systemd configuration.
Log files that point to /dev/null instead of being real files: auth.log, btmp, lastlog, wtmp, secure. That way, the evidence was erased before it could even be created.
Outbound connections to the mining pool gulf.moneroocean.stream on port 20004.
Missing or abruptly ending logs, unknown users in Proxmox's permission management, unexplained load.

If you find any of these signs, treat the system as fully compromised. After root access has been obtained, cleaning up is not a reliable option — the only fix is to rebuild from scratch and restore data from a backup that's demonstrably older than the breach.

What to do now

First: take port 8006 off the internet. This is the immediate measure and works regardless of version. Access only via VPN, an internal network, or a fixed IP allowlist. That's the correct way to run a management interface anyway.

Second: update. According to Proxmox, moving to a supported version is the only permanent fix. For Proxmox VE 7, that means jumping to a current branch, including the underlying Debian.

Third, if neither of those is possible right now: Proxmox provides a stopgap that restores the parameter check.

sed -i.bck 's/^\t# This is the 2nd factor, use the password for the OTP response.$/\tverify_ticket($tfa_challenge, 0, $username);\n\t# This is the 2nd factor, use the password for the OTP response./' /usr/share/perl5/PVE/AccessControl.pm

Then check whether the change took effect — the following command must output 3:

grep -n 'verify_ticket($tfa_challenge, 0, $username)' /usr/share/perl5/PVE/AccessControl.pm | wc -l

Then reload the services:

systemctl reload-or-restart pvedaemon pveproxy

This closes this one hole. It doesn't replace an update: a system without security support stays a system without security support, and the next flaw won't always be patchable by hand like this one.

Are Prepaid-Host customers affected?

No. Our virtualization runs on Proxmox VE 9, and the libpve-access-control version in use is well above the fixed 8.0.4. After the advisory, I didn't just spot-check — I went through every single host in our fleet and specifically searched for the breach indicators described above. All hosts are clean.

On top of that, there's the point that actually matters for this flaw: our Proxmox interfaces are not reachable from the internet. Management runs exclusively over internal addresses — and access to port 8006 is exactly the prerequisite for this attack. You don't need to do anything for your server with us.

It's different if you run Proxmox yourself, for example on a root server with us. In that case, the version is in your hands, and the checks above apply to you.

Sources

Frequently asked questions

Am I affected as a Prepaid-Host customer?

No. Our virtualization runs on Proxmox VE 9, well above the affected versions, and our management interfaces aren't reachable from the internet. After the advisory, we checked every host, including for signs of a breach. The flaw only affects you if you've installed Proxmox yourself on your own server.

Which Proxmox versions are affected by PSA-2026-00043-1?

The vulnerable package is libpve-access-control from version 7.0-7 up to but not including 8.0.4. That covers Proxmox VE 7.0 through 7.4, as well as the earliest 8.0 installations. It was fixed with libpve-access-control 8.0.4 on July 20, 2023. You can check with: dpkg-query -W -f '${Version}\n' libpve-access-control

How does the attack work technically?

In the login call POST /api2/json/access/ticket, the tfa-challenge parameter was never checked for accounts without a second factor. If an attacker sends this parameter with any value, the login skips the password check entirely. That lets them log in without any credentials as any activated user without two-factor enabled — by default, that includes root@pam.

Is the flaw being actively exploited?

Yes. Proxmox says it learned of the problem through several independent reports that also described exploitation in the wild. Affected users describe encrypted systems with ransom demands, as well as cryptominers planted on their hosts.

What should I do if I can't update my Proxmox VE 7 right away?

First, take port 8006 off the internet — access only via VPN or a fixed IP allowlist. That works immediately, regardless of version. Proxmox also provides a sed-based patch to /usr/share/perl5/PVE/AccessControl.pm, after which pvedaemon and pveproxy need to be reloaded. That's a stopgap and doesn't replace an update.

How do I tell if my server has already been compromised?

Watch for the file /var/lib/systemd/PVE-1, a PVE-1.service service, log files like auth.log or wtmp that are symlinked to /dev/null, and outbound connections to gulf.moneroocean.stream on port 20004. If you find any of these, treat the system as compromised: rebuild it and restore from a backup older than the breach.

Why did the flaw go unnoticed for over three years?

The bug was fixed in July 2023 as a side effect of a rework of the two-factor login, without anyone recognizing it as a security issue. As a result, there was no advisory and no backport to the Proxmox VE 7 branch, where the flaw stayed open until attackers found it.