Proxmox VE 7 : contournement d'authentification (CVE-2023-54391)

Un contournement d'authentification, remis en contexte

Fin août 2026, plusieurs administrateurs signalent sur le forum Proxmox des hôtes chiffrés et des journaux effacés, sous un titre sans détour : « Proxmox VE 7 is vulnerable to some type of 0day/RCE non auth ». La discussion hésite. Certains parlent d'un 0day, d'autres d'un vieux noyau Linux laissé sans correctif. Les deux lectures sont incomplètes, et la réalité se documente en quelques faits que cet article remet en ordre.

Le 1er septembre 2026, Proxmox publie l'advisory PSA-2026-00043-1 : un contournement d'authentification dans les versions en fin de vie de Proxmox VE 7. Un attaquant qui atteint l'interface de gestion peut se connecter en root@pam, le superutilisateur, sans fournir de mot de passe. Sur un hyperviseur, obtenir root sur l'hôte revient à prendre le contrôle de chaque machine virtuelle et de chaque conteneur qu'il héberge. La mention « RCE non auth » du titre n'est pas exacte au sens strict, mais sa conséquence l'est : un inconnu sur Internet et une seule requête suffisent à faire exécuter du code en root sur la machine qui fait tourner toute votre infrastructure.

Cet article démonte le mécanisme exact de la faille, explique pourquoi elle ressurgit trois ans après avoir été corrigée, vous donne de quoi vérifier si vous êtes exposé, et détaille la remédiation, du geste d'urgence à la reconstruction si vous êtes déjà compromis.

Les faits, tels que l'advisory les pose

Avant le mécanisme, le périmètre. Voici ce qui est établi, et ce qui ne l'est pas.

Deux précisions qui changent la lecture. D'abord, aucune version actuellement supportée n'est concernée : Proxmox VE 8.x à jour et 9.x embarquent le correctif depuis longtemps. Ensuite, sur la CVE elle-même, la communication a été confuse : certaines premières reprises annonçaient qu'aucun numéro n'était encore attribué et que le rapporteur s'apprêtait à le soumettre au MITRE, quand les bases de vulnérabilités le référencent désormais sous CVE-2023-54391. Nous retenons cet identifiant tout en gardant la réserve : sur un dossier aussi frais, une renumérotation n'est pas exclue.

La faille, ligne par ligne

Pour comprendre ce qui casse, il faut d'abord voir comment un login à deux facteurs est censé se dérouler dans Proxmox.

Quand vous vous connectez, le client envoie un POST sur /api2/json/access/ticket avec votre nom d'utilisateur, votre domaine d'authentification (le realm, pam, pve, LDAP, etc.) et votre mot de passe. Si le compte n'a pas de second facteur, le serveur valide le mot de passe et renvoie directement un ticket d'authentification, ce cookie signé qui autorise ensuite tous les appels d'API. Si le compte a un second facteur, le serveur ne délivre pas le ticket final tout de suite : il renvoie un ticket intermédiaire de challenge, et le client doit rejouer un second POST sur le même point d'entrée, cette fois avec le paramètre tfa-challenge qui porte ce ticket intermédiaire accompagné de la réponse du second facteur (le code TOTP, l'assertion WebAuthn, etc.). Le serveur vérifie ce challenge, et alors seulement délivre le ticket complet.

Tout le problème tient dans la façon dont le code décide s'il en est à la première ou à la seconde étape. Sur les versions vulnérables, cette décision repose sur la simple présence du paramètre tfa-challenge. Dès qu'il apparaît, le code considère qu'on est à l'étape de vérification du second facteur, et il saute la vérification du mot de passe : l'utilisateur est censé avoir déjà prouvé son mot de passe au tour précédent. Seulement, ce ticket intermédiaire, qui devait garantir que le premier tour a bien eu lieu, n'est pas validé pour un compte dépourvu de second facteur. Le code cherche à contrôler une réponse 2FA chez un utilisateur qui n'a pas de 2FA, ne trouve rien à vérifier, et au lieu de rejeter la demande, il la laisse passer.

Autrement dit, la garde qui devait dire « ce challenge est-il légitime ? » se contente, pour un compte sans second facteur, d'un « il y a bien un paramètre tfa-challenge, c'est donc l'étape 2, tout va bien ». La valeur de ce paramètre peut être n'importe quoi. Le mot de passe n'est jamais demandé. Le ticket complet est délivré.

La requête se réduit alors à ceci, et c'est ce qu'elle ne contient pas qui compte :

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

Notez ce qui manque : le champ password. C'est là que se joue le contournement. Le rapporteur, Nebu Security, a publié le mécanisme et un PoC, mais a choisi de ne pas diffuser la valeur exacte qui déclenche le passage, afin de freiner l'exploitation en copier-coller. Nous adoptons la même retenue : le schéma ci-dessus suffit à comprendre la faille et à la repérer dans vos journaux, sans en faire une arme prête à l'emploi. La nuance change peu de chose pour les attaquants déjà à l'œuvre ; elle compte pour le lecteur qui découvre le sujet.

De root@pam à l'exécution de code

Un ticket pour root@pam, ce n'est pas « un accès en lecture au tableau de bord ». root@pam est le compte adossé au root Unix réel de l'hôte, et l'API de Proxmox est, par conception, une télécommande complète de la machine. À partir de ce ticket, l'exécution de code n'est pas une seconde vulnérabilité à trouver, c'est une fonctionnalité :

• La console de l'hôte. L'interface expose un shell root sur le nœud via termproxy et un WebSocket (vncwebsocket), le même « Node → Shell » que vous utilisez tous les jours dans l'UI. Avec un ticket root, c'est un terminal root sur l'hyperviseur.
• L'exécution dans les invités. Sur toute VM dotée du guest agent, l'appel qemu-guest-agent exécute des commandes à l'intérieur de la machine virtuelle. Root sur l'hôte devient root dans les invités.
• Les scripts de sauvegarde et les hookscripts. Attacher un script déclenché au démarrage d'une VM ou à une sauvegarde, c'est planter une exécution de code persistante qui survit à un simple redémarrage.

C'est pourquoi le fil du forum parle de « RCE non auth » : entre la requête anonyme et le code qui tourne en root, il n'y a aucun mur intermédiaire à franchir. La faille n'exécute pas de code par elle-même, mais elle remet les clés à quelqu'un dont c'est ensuite le métier.

« 0day » ? Un correctif de 2023, une exploitation de 2026

C'est le point que le fil de forum n'a pas su trancher, et c'est le plus intéressant pour un défenseur.

Un 0day, au sens propre, est une faille exploitée avant qu'un correctif n'existe. Ce n'est pas le cas ici. Le bug a été corrigé en juillet 2023, dans libpve-access-control 8.0.4, à l'époque de la sortie de Proxmox VE 8.0. Sa particularité tient à la manière dont il l'a été : discrètement, sans CVE ni advisory, par une correction fondue dans un flot de mises à jour ordinaires. Pendant deux ans, la faille est restée corrigée pour qui suivait les mises à jour, et grande ouverte pour qui ne les suivait pas.

Or cette population est vaste. Proxmox VE 7.x est en fin de vie depuis juillet 2024 : plus de correctifs, plus de support, mais un parc installé considérable, parce qu'un hyperviseur qui « marche » se remplace rarement par confort. Fin août 2026, un acteur a retrouvé, analysé et rejoué ce vieux correctif silencieux, en a tiré un moyen d'attaque, et l'a lancé sur ce parc. Ce n'est donc pas un 0day, c'est un n-day : une faille ancienne, connue du code source depuis longtemps, transformée en arme contre les machines qui ont cessé de recevoir des correctifs. Pour vous, la distinction est capitale, parce qu'elle désigne le vrai risque : ce ne sont pas vos serveurs à jour qui sont visés, ce sont vos hyperviseurs oubliés, ceux dont plus personne ne se souvient qu'ils tournent.

Il y a là une leçon que l'on retrouve à chaque incident de ce genre : un correctif livré sans étiquette de sécurité protège moins bien qu'un correctif annoncé. Celui qui applique les mises à jour est couvert sans le savoir ; celui qui décide, faute d'annonce, qu'« il n'y a rien d'urgent ce mois-ci », reste vulnérable en croyant l'inverse. Le silence de 2023 est une partie de l'histoire de 2026.

Qui est touché, exactement

La ligne de partage est nette, ce qui rend le tri rapide.

Deux conditions doivent être réunies pour qu'un attaquant en profite, et chacune est une occasion de se protéger :

1. L'interface de gestion doit être joignable. L'API et l'UI vivent sur le port 8006. Un hôte dont ce port n'est accessible que depuis un réseau d'administration ou un VPN n'offre pas de surface à l'attaquant anonyme d'Internet.
2. Le compte visé ne doit pas avoir de second facteur. Le contournement ne fonctionne que pour un compte sans 2FA. Or root@pam n'en a pas par défaut. À l'inverse, un compte protégé par un TOTP ou une clé WebAuthn n'est pas contournable par cette faille : le code trouve un vrai second facteur à vérifier, et il le vérifie.

Ce second point est important parce qu'il transforme une mesure d'hygiène habituelle, activer le 2FA sur les comptes d'administration, en contre-mesure directe contre cette vulnérabilité précise.

Ce que font les attaquants une fois dedans

L'exploitation en cours n'est pas le fait d'un seul acteur. Au moins deux profils se partagent le parc : l'un déploie du rançongiciel (chiffrement du stockage, note de rançon), l'autre installe des mineurs de cryptomonnaie qui monétisent discrètement le CPU de l'hyperviseur. Les deux ont en commun un soin particulier à effacer leurs traces, et ce sont ces gestes anti-forensiques qui donnent les meilleurs indicateurs de compromission.

Les comportements observés et rapportés :

• Ouverture d'un shell root sans authentification préalable dans les journaux, juste avant que ceux-ci ne soient altérés.
• Journaux redirigés vers /dev/null : les fichiers de log sont remplacés par des liens symboliques vers /dev/null, si bien que tout ce qui s'écrit ensuite disparaît en silence. Un fichier de log qui est devenu un lien symbolique est un signal fort.
• Destruction de /var/lib/dpkg/status : ce fichier tient l'inventaire des paquets installés. Le supprimer casse la base de connaissance du gestionnaire de paquets, gêne l'analyse post-incident et brouille toute tentative de savoir ce qui a été modifié.
• Suppression des journaux existants : dans le cas initial du forum, tous les logs avaient été effacés, ne laissant qu'une adresse IP suspecte dans les dernières lignes.

Le scénario type raconté sur le forum réunit tous les ingrédients : un hôte en fin de vie depuis deux ans, un pare-feu désactivé le temps d'un déplacement, des VMs bien protégées derrière un CDN mais l'hôte lui-même exposé, un unique compte root avec un mot de passe de trente caractères. Le mot de passe long n'a servi à rien : la faille ne le demande pas.

Suis-je vulnérable ? Comment vérifier

Trois questions, dans l'ordre : ma version est-elle affectée, mon interface est-elle exposée, ai-je déjà été visité.

1. Version du paquet. C'est le juge de paix, plus fiable que le numéro de version affiché dans l'UI. Sur l'hôte :

# Version exacte du paquet fautif
dpkg -l libpve-access-control | grep '^ii'
 
# Vue d'ensemble
pveversion -v | grep -E 'pve-manager|libpve-access-control'

Si libpve-access-control est inférieur à 8.0.4, l'hôte est vulnérable. En pratique, toute installation restée en Proxmox VE 7.x l'est.

2. Exposition de l'interface. Depuis une machine hors de votre réseau d'administration, vérifiez si le port 8006 répond. S'il répond depuis Internet, c'est une urgence à part entière, indépendamment de la version :

# Le port de gestion répond-il là où il ne devrait pas ?
curl -sk -o /dev/null -w '%{http_code}\n' https://votre-hote:8006/

3. Traces d'exploitation. Le point d'entrée de connexion est journalisé par pveproxy. On y cherche les POST sur le ticket, en particulier ceux qui aboutissent à une session root@pam depuis une adresse inconnue :

# Tentatives de connexion à l'API, à recouper avec les IP légitimes
grep 'POST /api2/json/access/ticket' /var/log/pveproxy/access.log*
 
# Indicateur anti-forensique : un fichier de log devenu lien symbolique
find /var/log -maxdepth 3 -type l -ls
 
# Cohérence de l'inventaire de paquets (absent ou tronqué = suspect)
ls -l /var/lib/dpkg/status

Complétez par les vérifications d'usage après une suspicion de compromission d'hôte : crontab -l et /etc/cron.*, processus inconnus gourmands en CPU (top, un mineur ne se cache pas bien), clés SSH ajoutées dans /root/.ssh/authorized_keys, VMs ou conteneurs que vous ne reconnaissez pas. Un point désagréable : si l'attaquant a fait son travail, les journaux sont déjà partis. L'absence de trace n'est donc pas une preuve d'innocence sur un hôte exposé et vulnérable.

Côté outillage offensif public, la situation au moment où nous écrivons est claire : pas de module Metasploit ni d'entrée ExploitDB dédiée à CVE-2023-54391 (searchsploit proxmox ne remonte que de vieux tickets sans rapport et un brute-force TOTP). L'arme qui circule est un PoC autonome, ce qui n'est pas rassurant pour autant : un contournement d'authentification de ce type se réécrit en quelques lignes une fois le principe compris.

Que faire maintenant

Dans l'ordre du plus urgent au plus durable. Les deux premiers gestes prennent quelques minutes et referment la fenêtre immédiate ; les suivants règlent le problème de fond.

• Retirer l'interface 8006 d'Internet, tout de suite. C'est le geste qui coupe l'attaque, quelle que soit votre version. Le plan de gestion d'un hyperviseur n'a rien à faire en accès direct sur Internet : derrière un VPN, un bastion ou une liste d'adresses autorisées au niveau du pare-feu, jamais en frontal. Si vous ne deviez faire qu'une chose, c'est celle-là.
• Activer un second facteur sur root@pam et sur tous les comptes d'administration. Rappelons-le, un compte avec 2FA n'est pas contournable par cette faille. C'est une contre-mesure directe, pas seulement une bonne pratique générale.
• Appliquer le correctif. Sur une branche supportée, il suffit de mettre à jour : libpve-access-control 8.0.4 ou supérieur porte le correctif. Proxmox a par ailleurs mis à disposition un correctif d'appoint qui valide correctement le ticket de challenge, pour les environnements qui ne peuvent pas migrer dans l'heure.
• Migrer hors de Proxmox VE 7.x. C'est la seule réponse durable. La 7.x n'est plus maintenue depuis juillet 2024 : cette faille n'est qu'un symptôme, et le prochain n-day trouvera la même machine tout aussi démunie. La cible est une branche supportée, Proxmox VE 8.4.x ou 9.x. Sur un hôte en fin de vie, on ne bricole pas un paquet d'une autre branche majeure, on planifie une montée de version propre.
• En cas de compromission avérée, ne pas nettoyer, reconstruire. Un hôte sur lequel un inconnu a eu root n'est plus digne de confiance : rançongiciel ou mineur, on ne sait pas ce qui reste. Isoler la machine du réseau, préserver ce qui peut l'être pour l'analyse, restaurer les invités depuis des sauvegardes antérieures à l'intrusion et vérifiées, réinstaller l'hôte à neuf, puis faire tourner tous les secrets qui ont pu transiter : mots de passe, clés d'API, tokens, clés SSH, identifiants des invités.

Une leçon plus large : le plan de gestion ne se met pas sur Internet

Retirons-nous un instant du cas Proxmox, parce qu'il illustre un schéma qui nous occupe à longueur d'audits.

Une console d'administration exposée sur Internet est une bombe à retardement, indépendamment de sa marque. vSphere, un IPMI de carte mère, un hyperviseur, un contrôleur de stockage, un panneau de gestion : ce sont des surfaces à très haute valeur, où la moindre faille d'authentification donne, non pas un pied dans la porte, mais la maison entière. Le plan de gestion appartient à un réseau d'administration séparé, joignable par VPN ou bastion, point. Ici, la faille demande deux conditions, et l'exposition du port 8006 est celle que l'organisation contrôle entièrement, quand elle n'a aucune prise sur l'existence du bug.

La bonne question, après une alerte comme celle-ci, n'est pas seulement « suis-je à jour ? », c'est « qu'est-ce qui, chez moi, est joignable depuis Internet sans que je l'aie décidé ? ». Un hyperviseur oublié, une interface d'administration laissée en frontal « le temps d'un dépannage », un service de test qui n'a jamais été rangé. C'est exactement ce que révèle un inventaire de surface d'attaque externe, et ce qu'un scan de vulnérabilités bien ciblé recoupe avec les versions vulnérables connues, à condition que votre cartographie du système d'information contienne réellement ces machines. La faille du jour se corrige en une commande ; l'angle mort qui l'a laissée atteignable, lui, demande une démarche.

À ne pas confondre : CVE-2026-51083

Parce que les deux circulent en même temps et que les moteurs de recherche les mélangent, une mise au point. CVE-2026-51083 est une vulnérabilité distincte et bien moins grave. Elle touche le paquet qemu-server sur les branches supportées 8.x et 9.x, via le point d'entrée cloudinit/dump qui exposait des empreintes de mots de passe issues de la configuration cloud-init à des utilisateurs déjà authentifiés aux droits limités (défaut de contrôle d'accès, CWE-284, CVSS 6.5). Elle est corrigée dans qemu-server 8.4.8 et 9.1.8. Rien à voir avec le contournement d'authentification tfa-challenge : celle-ci demande un compte, ne donne pas root, et concerne les versions à jour. Si vous suivez les mises à jour, vous l'avez déjà refermée.

Questions fréquentes

Est-ce vraiment un 0day ?

Non, au sens strict. La faille a été corrigée en juillet 2023 dans libpve-access-control 8.0.4, mais sans CVE ni advisory à l'époque. Elle refait surface en 2026 parce qu'elle est désormais exploitée en masse sur les installations en fin de vie qui n'ont jamais reçu ce correctif. C'est un n-day, pas un 0day. La distinction n'est pas cosmétique : elle dit que vos machines à jour sont sûres et que le danger est concentré sur les hôtes oubliés.

Quelles versions de Proxmox VE sont concernées ?

Proxmox VE 7.0 à 7.4 (en fin de vie depuis juillet 2024) et le tout premier build de 8.0, soit libpve-access-control antérieur à 8.0.4. Toute version 8.x tenue à jour et toute 9.x sont corrigées.

Comment savoir si je suis touché ?

Sur l'hôte, dpkg -l libpve-access-control. Si la version est inférieure à 8.0.4, vous êtes vulnérable. Vérifiez aussi que le port 8006 n'est pas joignable depuis Internet.

J'ai activé le 2FA sur root, suis-je protégé ?

Contre cette faille précise, oui. Le contournement ne fonctionne que pour les comptes sans second facteur. Un compte protégé par un TOTP ou une clé WebAuthn n'est pas contournable par ce biais. Ce n'est pas une raison pour rester en 7.x : d'autres failles n'auront pas cette clémence.

Le mot de passe long de mon compte root me protège-t-il ?

Non. La faille ne teste pas le mot de passe, elle saute cette vérification. Un mot de passe de cent caractères est aussi inutile qu'un mot de passe vide face à ce contournement.

Comment passe-t-on de l'accès à l'exécution de code ?

Un ticket root@pam donne le plein contrôle de l'API, qui inclut l'ouverture d'un shell root sur l'hôte (console de nœud), l'exécution de commandes dans les invités via le guest agent, et l'attache de scripts persistants. L'exécution de code n'est pas une seconde faille, c'est une fonctionnalité de l'API désormais pilotée par un attaquant.

Existe-t-il un exploit public ?

Un PoC autonome circule, publié par le rapporteur (Nebu Security), qui a choisi de ne pas diffuser la valeur exacte du paramètre déclencheur. Il n'y a pas, à ce stade, de module Metasploit ni d'entrée ExploitDB dédiée. Cela ne réduit pas beaucoup le risque : le principe est simple à réimplémenter.

Mon hôte a été chiffré ou mine de la crypto, que faire ?

Considérer l'hôte comme définitivement compromis. L'isoler, restaurer les invités depuis des sauvegardes antérieures et vérifiées, réinstaller la machine à neuf, et faire tourner tous les secrets qui ont pu y transiter. Ne pas se contenter de retirer la charge visible : un accès root laisse rarement une seule porte.

CVE-2026-51083, c'est la même chose ?

Non. C'est une vulnérabilité distincte, une divulgation d'empreintes de mots de passe cloud-init dans qemu-server sur les versions supportées, corrigée en 8.4.8 et 9.1.8, qui demande un compte authentifié et ne donne pas root. À jour, vous êtes couvert.

Conclusion

Cette faille Proxmox n'est pas une prouesse technique : c'est une garde d'authentification mal posée, corrigée depuis deux ans, qui rattrape aujourd'hui tous ceux qui ont laissé un hyperviseur en fin de vie tourner sur Internet. La leçon n'est pas « Proxmox est dangereux », elle l'est autant que n'importe quel logiciel qu'on cesse de mettre à jour. La leçon est que le plan de gestion d'une infrastructure de virtualisation n'a rien à faire en frontal, qu'un second facteur sur les comptes d'administration transforme souvent une faille critique en non-événement, et qu'une machine qu'on a oublié de suivre finit par être suivie par quelqu'un d'autre.

Le geste d'urgence tient en une phrase : sortez le port 8006 d'Internet, activez le 2FA, planifiez la sortie de la 7.x. Le reste est une affaire de méthode.

Faites analyser votre exposition par Flawfence : nous cartographions ce qui, depuis Internet, répond en votre nom, hyperviseurs et interfaces d'administration compris, et nous vous disons quoi fermer en premier.

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 à 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, fiche CVE-2026-51083 (vulnérabilité distincte, qemu-server)
• Proxmox VE, page officielle des advisories de sécurité