A critical authentication vulnerability in older versions of Proxmox VE allows an attacker who can reach the management interface to attempt to gain access without knowing the account password. The issue, tracked as CVE-2023-54391, affects certain versions of libpve-access-control and also serves as a good reminder to check something more important than the patch itself: Proxmox, VMware vCenter, and any other infrastructure management plane should stay off public access whenever possible.
The Proxmox VE vulnerability in 30 seconds
- CVE-2023-54391 affects
libpve-access-controlfrom 7.0-7 up to versions earlier than 8.0.4. - Under certain conditions, the password check for an account without a second factor can be bypassed.
- The risk can extend to
root@pam, which explains its severity. - Currently supported versions of Proxmox VE are not affected.
- Besides updating, it’s worth taking port 8006 off the internet, and using private management networks, a firewall, and multi-factor authentication.
The flaw received a CVSS 3.1 score of 9.8 out of 10, placing it in the critical category. Proxmox has also explained an unusual circumstance: the code that removed the vulnerable path appeared in 2023, but at the time the change wasn’t treated as a security update, so it was never backported to the Proxmox VE 7 branch.
Years later, a public proof of concept now demonstrates the problem. That changes the picture considerably for any organization still running vulnerable installations, and especially for those that let their management interface be reached directly from the internet.
The priority should be updating. But the incident is also worth using as a small checklist for reviewing how your virtualization infrastructure is being protected.
How to tell if a Proxmox VE install could be affected
The first mistake to avoid is reducing the problem to “Proxmox 7 and earlier.”
The component named in the security advisory is:
libpve-access-control >= 7.0-7 and < 8.0.4
That corresponds roughly to Proxmox VE 7.0-7.4 and the initial Proxmox VE 8.0 release, but it's more accurate to check the installed package than to simply look at the platform's general version number.
From the console, you can check the version with:
pveversion -vYou can also check the specific package tied to the vulnerability:
dpkg -l libpve-access-controlIf the environment is running an old branch, the next thing to check is whether it's still within its support lifecycle.
Proxmox VE 7 reached end of support in July 2024. Keeping a virtualization platform out of support is a problem that goes beyond CVE-2023-54391: future vulnerabilities won't get the normal patch cycle reserved for supported versions either.
For an affected installation, the right fix isn't simply hiding the vulnerable port. You need to upgrade to a supported version of Proxmox VE, following the vendor's recommended upgrade procedure and checking compatibility, repositories, storage, cluster, and backups beforehand.
Port 8006 shouldn't be open to the whole internet
Proxmox VE typically uses TCP 8006 for its web interface and management API.
A simple test from outside the corporate network can show whether the interface responds on a public IP address. It's also worth reviewing the perimeter firewall, NAT rules, and any port forwarding set up on routers or security appliances.
The fact that Proxmox needs connectivity doesn't mean its management console has to be public.
It's worth distinguishing between the networks used by virtual machines and the hypervisor's management network.
A reasonable enterprise architecture can separate, depending on the environment's size and requirements, user and application traffic, storage, cluster, migration, and administration.
The administrative interface should only be reachable from authorized networks.
A common approach is to use a dedicated management VLAN or private network. Administrators access it through a corporate VPN or from pre-authorized machines.
Another option is a bastion host or jump host: a controlled machine that acts as the entry point into administrative systems.
The firewall should complete that separation.
Instead of allowing:
Internet → TCP 8006 → Proxmox VEthe architecture should look more like:
Administrator → VPN/corporate network → private management network → Proxmox VEVirtual machines don't need to follow the same path. A web server hosted on Proxmox can expose ports 80 and 443 to the internet while the node's management stays completely separate.
It's precisely that separation between public services and the management plane that reduces the impact of vulnerabilities like CVE-2023-54391.
What else to check besides updating Proxmox
Updating should be the first step whenever a known vulnerability exists, but a virtualization environment needs several layers of protection.
One of them is multi-factor authentication (MFA) for administrative accounts. In the specific case of CVE-2023-54391, the condition involving accounts without a second factor matters a great deal.
It's also worth reviewing existing accounts and removing any that are no longer used. Administrative accounts should only be granted to the people and services that genuinely need them.
Firewall rules deserve another look. It isn't enough to check Proxmox's own firewall if a perimeter device is directly exposing the service. NAT rules, access control lists, and any leftover rule from a past change or migration should all be reviewed.
Logs can also provide useful information.
Proxmox uses services like pveproxy and pvedaemon, whose events can be reviewed with journalctl:
journalctl -u pveproxyjournalctl -u pvedaemonIn an environment where an intrusion is suspected, the review should extend to authentications, accounts, administrative changes, virtual machines, scheduled tasks, SSH keys, and other indicators. Updating a server that has already been compromised doesn't necessarily undo actions an attacker took beforehand.
It's also advisable to keep backups independent of the cluster itself. Proxmox's high availability can recover services from certain node failures, but it's no substitute for a backup strategy.
The same distinction applies to snapshots and replication: they're different tools and shouldn't automatically be treated as backups against every attack scenario.
VMware vCenter should follow exactly the same philosophy
CVE-2023-54391 affects Proxmox, but the security architecture that limits its exposure applies just as well to VMware vCenter.
vCenter holds a privileged administrative position over a VMware environment. It can act on ESXi hosts, virtual machines, permissions, networks, and other infrastructure functions.
For that reason, it shouldn't be exposed directly to the internet either, unless there's an exceptional need and an architecture specifically designed for it.
Broadcom recommends restricting access to vCenter to authorized IP addresses and subnets. In an enterprise environment, it's preferable for both vCenter and the ESXi hosts themselves to sit on controlled administrative networks.
The same recommendation extends to storage arrays, IPMI, iDRAC, or iLO interfaces, backup systems, switches, firewalls, and any console capable of modifying the infrastructure.
There's a good question worth asking when taking inventory:
Which of the company's management interfaces can currently be reached from any IP address on the internet?
If Proxmox, vCenter, a server controller, or a storage array's management console shows up, it's worth figuring out why.
Migrating from VMware to Proxmox is also a chance to review security
Many companies are currently evaluating a migration from VMware to Proxmox VE. Switching hypervisors shouldn't be treated purely as an exercise in moving virtual machines.
It's also a chance to redesign elements that may have gone years without a full review.
The new platform can separate management networks from the outset, set up multi-factor authentication, establish firewall policies, review shared storage, properly configure the cluster and high availability, and design an independent backup and disaster-recovery strategy.
It also helps avoid a practice still found in some small installations: assigning a public address to the hypervisor simply because it makes remote administration easier.
It's convenient, but better alternatives exist.
A VPN, a private network linking to company offices, or a controlled administrative access system all make it possible to manage Proxmox without exposing its interface directly.
And that choice will keep paying off long after CVE-2023-54391 is patched.
A quick checklist for hardening a Proxmox VE environment
A basic review should check the version of Proxmox and of libpve-access-control, update any branch that's out of support, verify that TCP 8006 isn't globally open to the internet, move administration to a private network, restrict access with a firewall and VPN, enable MFA for administrators, and remove unnecessary accounts.
It's also worth reviewing authentication and administration logs, separating management, cluster, and storage networks where needed, protecting physical hardware management interfaces, and keeping independent, tested backups.
No configuration eliminates every future vulnerability. The advantage of this design is different: it reduces the number of attackers able to reach them in the first place.
CVE-2023-54391 will eventually fade away as old installations are retired. There will be other vulnerabilities in Proxmox, VMware, operating systems, storage, and network devices.
The best preparation for the next one isn't just waiting for the patch. It's making sure that, when it arrives, the vulnerable interface isn't sitting there waiting for connections from anywhere on the internet.
Frequently asked questions
How do I check if Proxmox VE is affected by CVE-2023-54391?
You should specifically check the version of libpve-access-control. The affected range starts at 7.0-7 and ends before 8.0.4; pveversion -v gives detailed information about the installed components.
Is it safe to have Proxmox's port 8006 open to the internet?
It isn't a recommended setup for an enterprise environment. It's preferable to keep the administrative interface on a private network and access it through a VPN, authorized networks, or a controlled jump system.
Is updating Proxmox enough to fix the problem?
The update fixes the known vulnerability, but it's worth using the incident to review public exposure, firewall rules, MFA, administrative accounts, and logs. If there are signs of prior exploitation, updating alone doesn't rule out a compromise.
What should I check when migrating from VMware to Proxmox?
Beyond virtual machines and compatibility, you should review management networks, storage, high availability, backup, disaster recovery, firewall, MFA, and remote access. A migration is a good moment to make sure the new administrative console doesn't end up directly exposed to the internet.
Sources:
- Proxmox Server Solutions, PSA-2026-00043-1, advisory on the authentication bypass in older Proxmox VE versions.
- Proxmox VE Administration Guide, documentation on administration, firewall, and web interface access.
- CVE-2023-54391, vulnerability record and CVSS assessment.
- Broadcom, security documentation on restricting administrative access to VMware vCenter Server.
