A critical authentication vulnerability affects older Proxmox VE 7 installations and the initial Proxmox VE 8.0 release, potentially allowing a remote attacker who can reach the management API to obtain a valid session without knowing the account password. The vulnerability, tracked as CVE-2023-54391 and acknowledged by Proxmox in security advisory PSA-2026-00043-1 on September 1, 2026, is also a reminder of a basic infrastructure security principle: hypervisor management interfaces should not be directly exposed to the public Internet.
The key facts about the Proxmox VE vulnerability in 20 seconds
- The flaw affects
libpve-access-controlversions from 7.0-7 up to, but not including, 8.0.4. - Under specific conditions, an unauthenticated attacker can bypass password verification for accounts without two-factor authentication.
- This can potentially include
root@pam, providing administrative access to the environment. - Proxmox VE 7 has been unsupported since July 2024, and currently supported releases are not affected.
- Proxmox, vCenter and other infrastructure management interfaces should normally remain on private management networks.
One unusual aspect of the vulnerability is its history. The code change that removed the vulnerable authentication path had already appeared in July 2023 with libpve-access-control 8.0.4, but its security implications were not understood at the time.
Proxmox has since explained that the vulnerable path disappeared as a side effect of changes related to two-factor authentication handling. Because the modification was not considered a security fix, it was not backported to the Proxmox VE 7 branch.
The issue took on much greater significance in 2026 after reports emerged suggesting that vulnerable systems exposed to the Internet could be targeted. Proxmox subsequently published its security advisory, and the vulnerability was assigned CVE-2023-54391.
The vulnerability can bypass password authentication
The flaw is located in libpve-access-control, a component involved in Proxmox VE authentication.
Affected package versions range from 7.0-7 to versions earlier than 8.0.4. This roughly corresponds to Proxmox VE 7.0 through 7.4 and the initial Proxmox VE 8.0 release, although administrators should verify the installed package version rather than relying solely on the overall PVE release number.
The vulnerability involves the handling of a two-factor authentication challenge when an access ticket is created.
Under certain circumstances, a specially crafted request can supply an arbitrary value for this challenge and cause the system to skip normal password verification for an existing and enabled account that does not have a second authentication factor configured.
The consequences become particularly serious when the targeted account is root@pam.
CVE-2023-54391 has received a CVSS 3.1 score of 9.8 out of 10, placing it in the critical category. Exploitation does not require an existing authenticated account or administrator interaction.
Public proof-of-concept material has also demonstrated how the behavior can be reproduced against vulnerable systems. Given the severity and simplicity of the attack path, publishing step-by-step exploitation instructions adds little value for defenders. Administrators should instead determine whether vulnerable systems exist, remove public access to their management interfaces and upgrade them.
There is another important distinction: describing the issue simply as affecting “Proxmox 7 and earlier” is inaccurate. The vulnerable component is specifically identified as libpve-access-control >= 7.0-7 and < 8.0.4.
Modern, supported Proxmox VE versions are not affected.
The strongest protection starts before the patch
CVE-2023-54391 highlights a security problem that extends beyond the software bug itself.
The Proxmox VE web management interface normally operates over TCP port 8006. That port needs to be reachable by administrators, but there is usually no reason for it to be reachable by every host on the Internet.
Enterprise deployments should normally use a dedicated private management network for infrastructure administration.
Administrators can then reach that network through controlled mechanisms such as a corporate VPN, restricted administrative networks, a bastion or jump host, or another appropriately secured access layer.
This distinction matters because patching and network segmentation protect against different problems.
A patch removes a known vulnerability. Segmentation can reduce exposure to vulnerabilities that have not yet been discovered or disclosed.
If the Proxmox management interface cannot be reached from the public Internet, a remote attacker first needs to overcome another security boundary before attempting to exploit the hypervisor management layer.
Two-factor authentication provides another useful layer and should be enabled for privileged accounts. In this particular vulnerability, accounts protected with a second factor are not exposed to the same authentication bypass path described in the advisory.
But MFA should not be used as justification for unnecessarily publishing an infrastructure management interface on a public IP address.
vCenter should not be exposed to the Internet either
The same principle applies to VMware infrastructure.
vCenter Server is a central management component for VMware environments. Depending on the deployment, it can provide control over ESXi hosts, virtual machines, permissions, networking and other parts of the virtual infrastructure.
That makes vCenter an exceptionally valuable target.
There is normally little justification for making its administrative interface directly accessible from the public Internet. Broadcom provides mechanisms for restricting vCenter access to specific IP addresses and subnets, allowing organizations to limit which management systems can communicate with it.
The principle extends well beyond Proxmox and VMware.
Hypervisor consoles, storage arrays, backup servers, network switches, firewalls, cloud management platforms and other infrastructure controllers should all be evaluated with the same question: does this management service genuinely need to accept connections directly from the Internet?
In many environments, the answer will be no.
This does not mean that workloads hosted on the infrastructure must also be private. Virtual machines can expose websites, APIs, mail services and other applications while the systems used to administer the underlying infrastructure remain isolated.
The important architectural distinction is between the service plane and the management plane.
A compromised web application may give an attacker access to one workload. Compromising the system that controls the hypervisor can potentially provide access to many workloads, their virtual disks, networking and administrative operations.
Proxmox VE 7 users should upgrade
There is another important factor for organizations still operating Proxmox VE 7: the platform reached the end of its support lifecycle in July 2024.
Running that branch in 2026 therefore means relying on software that no longer receives the normal security maintenance provided to supported Proxmox VE releases.
Proxmox has documented mitigation options for affected environments that cannot be upgraded immediately, but moving to a supported release should be the longer-term response. The vendor states that no currently supported Proxmox VE release is affected by CVE-2023-54391.
The incident is also relevant to organizations currently considering a migration from VMware to Proxmox VE.
Moving between hypervisors should involve more than transferring virtual machines from one platform to another. It provides an opportunity to reconsider the architecture around them: dedicated management networks, clustering, shared storage, high availability, independent backups, disaster recovery, multifactor authentication, firewall policies and update procedures.
Migrating from VMware to Proxmox while leaving the new management console directly exposed to the Internet would simply carry a poor security practice from one platform to another.
CVE-2023-54391 illustrates why infrastructure design matters even when all available patches have been installed.
The vulnerability existed for years before its security impact became clear. Organizations cannot realistically assume that their hypervisor, management console or storage platform contains no undiscovered vulnerabilities.
They can, however, control which management systems will be reachable from the Internet when the next vulnerability is discovered.
Frequently asked questions
Which Proxmox VE versions are affected by CVE-2023-54391?
The advisory identifies libpve-access-control versions from 7.0-7 up to, but not including, 8.0.4. This roughly covers Proxmox VE 7.0-7.4 and the initial Proxmox VE 8.0 release. These releases are now outside the currently supported Proxmox VE branches.
Can an attacker access Proxmox without knowing the password?
Under the conditions described in the vulnerability, an attacker can bypass password verification for an existing enabled account without two-factor authentication. This can potentially include root@pam.
Should Proxmox port 8006 be publicly accessible?
In enterprise environments, direct public exposure should normally be avoided. A safer architecture keeps management interfaces on private networks and provides administrative access through controlled VPNs, restricted networks or bastion systems.
Should VMware vCenter be accessible from the Internet?
The same security principle applies to vCenter. Management access should be restricted to trusted networks and administrative systems rather than exposed unnecessarily to the public Internet.
Sources:
- Proxmox Server Solutions, PSA-2026-00043-1: Authentication bypass in EOL Proxmox VE 7 release.
- Proxmox VE Administration Guide.
- CVE-2023-54391 vulnerability record and CVSS information.
- NebuSec, technical analysis and disclosure timeline for PSA-2026-00043-1.
- Broadcom, vCenter Server access restriction and hardening documentation.