CVE-2023-54391 : faille Proxmox de contournement d'authentification

Dans le cadre de notre veille sécurité, nous signalons CVE-2023-54391, une vulnérabilité critique affectant d’anciennes versions de Proxmox Virtual Environment.

La faille permet de contourner entièrement l’authentification de l’API Proxmox. Un attaquant capable d’atteindre le port d’administration peut se connecter comme un utilisateur existant qui ne possède pas de second facteur, sans connaître son mot de passe. Dans une configuration courante, cela peut inclure le compte hautement privilégié root@pam.

Le score CVSS 3.1 de 9,8/10 reflète un scénario particulièrement sévère : attaque à distance, complexité faible, aucune authentification préalable et impact potentiel sur la confidentialité, l’intégrité et la disponibilité de toute la plateforme.

La bonne nouvelle est importante : aucune version actuellement supportée de Proxmox VE n’est vulnérable. Le code affecté a été modifié en juillet 2023 et la correction est présente dans libpve-access-control 8.0.4 et toutes les versions ultérieures.

La mauvaise nouvelle l’est tout autant : Proxmox VE 7 est encore présent dans de nombreux environnements non maintenus, parfois exposés directement ou indirectement à Internet. Proxmox indique par ailleurs avoir reçu plusieurs signalements indépendants mentionnant une exploitation dans la nature.

Une CVE publiée en 2026 pour une faille corrigée depuis 2023

L’identifiant CVE-2023-54391 peut sembler paradoxal dans une alerte publiée en septembre 2026.

Le chemin vulnérable existait dans les anciennes branches Proxmox et a disparu en juillet 2023, lors d’une réorganisation du traitement de l’authentification à deux facteurs. À ce moment-là, le changement n’était pas identifié comme un correctif de sécurité. Il n’avait donc pas été présenté comme tel ni rétroporté vers Proxmox VE 7.

La vulnérabilité n’a été comprise et signalée que beaucoup plus tard. Le 1er septembre 2026, Proxmox a publié l’avis PSA-2026-00043-1 après avoir reçu plusieurs rapports indépendants au cours des deux jours précédents.

Ce décalage illustre une réalité de l’exploitation : un logiciel peut avoir reçu indirectement une correction depuis des années, tandis que ses anciennes branches restent vulnérables parce que personne ne savait encore qu’un correctif de sécurité devait y être rétroporté.

Or Proxmox VE 7 est en fin de vie depuis juillet 2024. Il ne reçoit plus les corrections de sécurité du projet, ni pour la pile Proxmox elle-même, ni pour les composants sous-jacents comme le noyau Linux, QEMU ou LXC.

Comment fonctionne le contournement d’authentification

L’interface web et les clients Proxmox utilisent l’API d’accès, généralement disponible en HTTPS sur le port 8006.

Lorsqu’un utilisateur protégé par un second facteur saisit correctement son mot de passe, Proxmox lui remet normalement un ticket intermédiaire signé. Ce ticket, transmis dans le paramètre tfa-challenge, prouve que la première étape de l’authentification a réussi et permet ensuite de valider le code à usage unique.

Dans les versions vulnérables, deux comportements se combinent :

1. la présence de tfa-challenge indique au serveur que le mot de passe a déjà été vérifié ;
2. pour un compte sans second facteur configuré, la valeur du challenge n’est pas correctement validée.

Un attaquant peut donc appeler POST /api2/json/access/ticket, fournir le nom d’un utilisateur actif et placer une valeur arbitraire dans tfa-challenge. Le serveur saute alors la vérification du mot de passe et accepte un challenge qui ne devrait avoir aucune valeur.

Ce n’est pas une attaque par force brute et elle ne nécessite pas de voler un mot de passe. L’erreur porte directement sur la logique qui décide si l’identité a déjà été vérifiée.

Versions de Proxmox concernées

L’avis de l’éditeur définit l’exposition à partir du paquet réellement installé :

Composant	Versions affectées	État
libpve-access-control	>= 7.0-7 et < 8.0.4	Vulnérable
Proxmox VE 7.0 à 7.4	Correspondance approximative	Vulnérable et EOL
Première version Proxmox VE 8.0	Selon le paquet installé	Ancienne version EOL
libpve-access-control 8.0.4 et ultérieures	Correction incluse	Non vulnérable à cette CVE
Versions Proxmox actuellement supportées	Correction incluse	Non vulnérables à cette CVE

Le numéro global de Proxmox VE et la version d’une dépendance ne progressent pas toujours ensemble. Il faut donc contrôler le paquet, pas seulement le bandeau de l’interface web.

Pourquoi des environnements EOL restent encore en production

La fin de support d’une version ne provoque pas son arrêt automatique. Dans la réalité, les anciennes plateformes persistent pour des raisons très ordinaires :

• un cluster fonctionne correctement et personne ne veut provoquer d’interruption ;
• un ancien prestataire n’assure plus la maintenance ;
• la documentation, les accès ou les responsabilités sont incomplets ;
• une application historique bloque l’évolution de certaines VM ;
• le matériel ou les pilotes n’ont pas été requalifiés avec une version récente ;
• un environnement de test a progressivement accueilli des services réels ;
• un site distant ou une filiale est sorti de l’inventaire principal ;
• la migration est reportée parce qu’elle impose de vérifier sauvegardes, stockage, réseau et compatibilité des invités.

Ces systèmes sont souvent moins visibles que les plateformes récemment déployées. Ils sont pourtant très intéressants pour un attaquant : interface d’administration ancienne, comptes historiques, exposition réseau mal documentée et accumulation de vulnérabilités non corrigées.

Le principal enseignement de CVE-2023-54391 n’est donc pas qu’une version actuelle de Proxmox serait fragile. Il est qu’un hyperviseur oublié ne cesse pas d’être critique parce qu’il est ancien. Au contraire, sa capacité à accéder aux VM, aux consoles, aux disques virtuels, aux sauvegardes et aux réseaux lui donne une valeur durable.

Vérifier l’exposition sans tester la faille

Il n’est pas nécessaire, ni recommandé, d’essayer de contourner l’authentification sur un serveur de production.

Relevez la version du paquet concerné :

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

La commande suivante affiche également l’ensemble des versions de la pile Proxmox :

pveversion -v

Une version de libpve-access-control comprise entre 7.0-7 inclus et 8.0.4 exclu est affectée.

Pour automatiser la qualification locale sans envoyer de requête d’exploitation :

version=$(dpkg-query -W -f='${Version}' libpve-access-control 2>/dev/null) && if dpkg --compare-versions "$version" ge 7.0-7 && dpkg --compare-versions "$version" lt 8.0.4; then echo "ALERTE : version potentiellement vulnérable ($version)"; else echo "Version hors de la plage vulnérable ($version)"; fi

Vérifiez ensuite les chemins permettant de joindre l’API :

• publication directe du port 8006 ;
• reverse proxy placé devant l’interface ;
• accès VPN trop large ou comptes de prestataires anciens ;
• réseau d’administration partagé avec des postes utilisateurs ;
• règles de pare-feu devenues obsolètes ;
• DNS public révélant une interface qui devait rester interne.

La commande locale suivante confirme uniquement que le service écoute. Elle ne prouve pas qu’il est accessible depuis Internet :

ss -lntp | grep ':8006'

La portée réelle doit être vérifiée depuis les différentes zones réseau et dans les configurations du pare-feu, du reverse proxy et du VPN.

Vous exploitez encore un environnement Proxmox ancien ?

Forget About IT conçoit, reprend et maintient des infrastructures Proxmox, Linux et hyperconvergées. Nous pouvons intervenir pour inventorier un environnement historique, qualifier son exposition à CVE-2023-54391, sécuriser temporairement son accès et préparer une migration sans improviser sur la production.

L’intervention peut couvrir :

• l’audit des versions, accès, réseaux, stockages et sauvegardes ;

• la vérification des clusters, VM, conteneurs et dépendances critiques ;

• la réduction immédiate de l’exposition de l’interface d’administration ;

• la préparation d’un chemin de mise à niveau réaliste ;

• les sauvegardes et tests de restauration avant changement ;

• la migration par étapes et les contrôles après intervention ;

• l’investigation si une exploitation est suspectée.

• Découvrir notre offre d’infogérance Linux et Proxmox

• Nous contacter pour qualifier un environnement

• Prendre rendez-vous

Quel serait l’impact d’une exploitation réussie ?

Le compte root@pam dispose des droits les plus élevés dans une installation Proxmox courante. Son usurpation donne à l’attaquant la maîtrise de la couche qui administre l’infrastructure virtualisée.

Selon l’architecture et les droits du compte visé, les conséquences peuvent inclure :

• arrêt, démarrage, création, modification ou suppression de VM et de conteneurs ;
• accès aux consoles des systèmes invités ;
• montage, copie ou export de disques virtuels ;
• consultation des configurations réseau et stockage ;
• création de comptes, de jetons API ou de mécanismes de persistance ;
• récupération de secrets présents dans les configurations ou les VM ;
• interruption des sauvegardes avant une opération destructive ;
• déplacement latéral vers les services hébergés.

La compromission d’un hyperviseur ne doit pas être traitée comme celle d’une application isolée. L’hyperviseur concentre les plans de contrôle, les données et les chemins d’administration de plusieurs systèmes. Une seule authentification contournée peut donc remettre en cause l’intégrité de l’ensemble du périmètre.

Que faire immédiatement ?

1. Réduire l’accès au port 8006

L’API et l’interface d’administration ne doivent être accessibles que depuis des réseaux de confiance, un bastion ou un VPN correctement contrôlé.

Cette restriction réduit fortement l’exposition, mais elle ne corrige pas la faille. Un poste compromis dans le réseau autorisé ou un accès VPN détourné peut toujours atteindre le service.

2. Vérifier tous les comptes et activer le 2FA

Les comptes qui possèdent un second facteur ne sont pas exploitables par ce chemin. Il faut néanmoins vérifier tous les realms et tous les comptes actifs, pas uniquement les comptes administrateurs les plus visibles.

L’activation du 2FA constitue une défense supplémentaire utile. Elle ne transforme pas une branche EOL en plateforme maintenue et ne corrige pas les autres vulnérabilités accumulées depuis sa fin de support.

3. Appliquer la mitigation officielle si la migration doit attendre

Proxmox fournit une modification temporaire pour les installations qui ne peuvent pas encore être mises à niveau. Elle ajoute la validation du ticket tfa-challenge dans le fichier concerné, puis recharge les services d’administration.

Cette opération modifie directement un fichier Perl installé par le paquet. Elle doit être préparée, sauvegardée et contrôlée. La commande de vérification fournie par Proxmox doit retourner exactement 3 occurrences ; tout autre résultat signifie que la mitigation ne s’est pas appliquée correctement.

Les commandes à jour et la procédure de retour arrière doivent être reprises directement depuis l’avis PSA-2026-00043-1 de Proxmox.

4. Migrer vers une version supportée

La seule réponse durable est de sortir de Proxmox VE 7 et de toute première installation 8.0 restée sans mises à jour.

Une migration sérieuse commence avant la mise à niveau des paquets :

1. documenter le cluster, le quorum, les réseaux, stockages et dépôts ;
2. vérifier la compatibilité matérielle et les changements de configuration ;
3. contrôler les sauvegardes et effectuer un test de restauration ;
4. traiter les paquets tiers et personnalisations locales ;
5. suivre le chemin de mise à niveau supporté par Proxmox ;
6. intervenir nœud par nœud lorsque l’architecture le permet ;
7. vérifier les VM, conteneurs, sauvegardes, réplications et mécanismes HA ;
8. conserver une preuve des versions réellement installées après l’opération.

Pourquoi la mitigation seule ne suffit pas

Le correctif temporaire cible précisément CVE-2023-54391. Il ne remet pas à niveau le noyau Linux, QEMU, LXC, les bibliothèques système, l’interface web ni les autres composants d’une installation restée figée.

Un environnement EOL peut donc être protégé contre ce contournement d’authentification tout en restant exposé à plusieurs années de vulnérabilités indépendantes.

C’est aussi la raison pour laquelle une simple fermeture du port public ne doit pas devenir une solution permanente. La segmentation réseau réduit la surface d’attaque, mais elle ne remplace ni la maintenance ni la maîtrise du cycle de vie.

Si une exploitation est suspectée

Proxmox rapporte des signalements d’exploitation dans la nature. Une installation vulnérable dont l’API était atteignable par un réseau non fiable mérite donc plus qu’une simple mise à jour.

Les premières mesures consistent à :

• préserver les journaux avant leur rotation ;
• examiner les authentifications, tickets, tâches et appels API inhabituels ;
• inventorier les comptes, groupes, rôles et jetons API ;
• rechercher les changements apportés aux VM, conteneurs, stockages et sauvegardes ;
• vérifier les clés SSH et fichiers de configuration sur les nœuds ;
• isoler l’accès d’administration si l’intégrité est incertaine ;
• faire tourner les secrets accessibles depuis l’hyperviseur ;
• contrôler séparément les systèmes invités pouvant avoir été consultés ou modifiés.

L’installation d’une version corrigée ferme la vulnérabilité, mais n’efface pas une persistance créée auparavant et ne restaure pas la confiance dans une plateforme déjà compromise.

Notre lecture opérationnelle

CVE-2023-54391 ne remet pas en cause les versions supportées de Proxmox VE. Elle met en lumière un problème plus large : les infrastructures oubliées continuent d’héberger des services, mais elles ne continuent pas à recevoir des correctifs.

La priorité doit donc être double :

• traiter immédiatement les installations présentes dans la plage vulnérable ;
• rechercher les hyperviseurs, clusters et interfaces d’administration qui ne figurent plus dans le cycle normal de maintenance.

Une bonne veille CVE n’est utile que si elle s’appuie sur un inventaire réel, des responsables identifiés, des accès maîtrisés, des sauvegardes testées et une capacité d’intervention. Sans cela, l’alerte la plus critique peut rester sans effet simplement parce que personne ne sait qu’un ancien serveur est encore en ligne.

Conclusion

CVE-2023-54391 est un contournement critique de l’authentification dans les anciennes versions de Proxmox VE. Un attaquant pouvant joindre l’API peut usurper un compte actif sans 2FA, potentiellement root@pam, sans connaître son mot de passe.

Les versions supportées sont déjà protégées. L’urgence concerne les environnements Proxmox VE 7.x et les premières installations 8.0 restées sans maintenance.

Le bon ordre d’action est clair :

• inventorier les serveurs Proxmox, y compris les sites et clusters oubliés ;
• vérifier la version exacte de libpve-access-control ;
• restreindre immédiatement l’accès au port 8006 ;
• contrôler les comptes et le 2FA ;
• appliquer la mitigation officielle si nécessaire ;
• préparer la migration vers une version supportée ;
• investiguer les installations vulnérables qui étaient exposées.

Cette faille rappelle surtout qu’une infrastructure stable n’est pas nécessairement une infrastructure sûre. Lorsqu’un hyperviseur sort du cycle de maintenance, le risque continue de croître même si les VM qu’il héberge semblent fonctionner normalement.

Sources

• Proxmox - PSA-2026-00043-1 : Authentication bypass in EOL Proxmox VE 7 release
• NVD - CVE-2023-54391
• CVE.org - CVE-2023-54391
• Proxmox Git - modification du traitement TFA intégrée en juillet 2023
• CTIR Gov - recommandation technique sur CVE-2023-54391

FAQ : CVE-2023-54391 et Proxmox VE

Qu’est-ce que CVE-2023-54391 ?

CVE-2023-54391 est un contournement d’authentification dans libpve-access-control. Un attaquant pouvant joindre l’API d’une version affectée peut présenter un tfa-challenge arbitraire et se connecter comme un compte actif sans second facteur, sans connaître son mot de passe.

Quelles versions de Proxmox sont vulnérables ?

Les versions affectées de libpve-access-control vont de 7.0-7 inclus à 8.0.4 exclu. Cela correspond approximativement à Proxmox VE 7.0 à 7.4 et à la première version 8.0. Ces branches sont aujourd’hui en fin de vie.

Les versions Proxmox actuelles sont-elles concernées ?

Non. Proxmox indique qu’aucune version actuellement supportée n’est affectée. La modification qui ferme la faille est présente depuis libpve-access-control 8.0.4, publié en juillet 2023.

Comment vérifier un serveur Proxmox ?

Utilisez dpkg-query ou pveversion -v pour relever la version réellement installée de libpve-access-control. Vérifiez ensuite si le port 8006 est accessible depuis Internet, un reverse proxy, un VPN trop large ou un réseau utilisateur.

Le 2FA bloque-t-il l’exploitation ?

Le chemin décrit ne fonctionne pas contre un compte qui possède un second facteur. Il suffit toutefois qu’un compte actif sans 2FA reste présent pour conserver une exposition. L’activation du 2FA réduit le risque, mais ne remplace pas la migration d’une version EOL.

Faut-il seulement appliquer la mitigation fournie par Proxmox ?

Non. La mitigation corrige temporairement ce chemin précis, mais pas les autres vulnérabilités accumulées par une ancienne branche. La réponse durable consiste à migrer vers une version supportée et à vérifier l’intégrité de toute installation qui a été exposée.