Une vulnérabilité critique d’authentification dans les versions anciennes de Proxmox VE permet à un attaquant pouvant atteindre l’interface d’administration d’essayer d’obtenir un accès sans connaître le mot de passe du compte. Ce problème, identifié sous le nom de CVE-2023-54391, concerne certaines versions de libpve-access-control et constitue également un rappel important pour revoir un aspect encore plus crucial que le simple patch : Proxmox, VMware vCenter et toute autre interface de gestion d’infrastructure doivent idéalement rester hors de portée du public, autant que possible.

Les essentiels de la vulnérabilité Proxmox VE en 30 secondes

• Le CVE-2023-54391 impacte libpve-access-control depuis la version 7.0-7 jusqu’aux versions antérieures à 8.0.4.
• En certaines conditions, il peut être évité de vérifier le mot de passe d’un compte activé sans second facteur.
• Le risque peut concerner root@pam, ce qui accentue sa gravité.
• Les versions actuellement supportées de Proxmox VE ne sont pas affectées.
• Outre la mise à jour, il est conseillé de retirer le port 8006 d’Internet, d’utiliser des réseaux privés de gestion, un pare-feu et l’authentification multifactorielle.

Ce défaut a reçu une note CVSS 3.1 de 9,8 sur 10, dans la catégorie critique. Proxmox a aussi expliqué une circonstance peu courante : le code ayant éliminé la voie vulnérable est apparu en 2023, mais cette modification n’a pas été considérée comme une mise à jour de sécurité à l’époque, et n’a donc pas été transférée dans la branche Proxmox VE 7.

Plusieurs années plus tard, une preuve de concept publique existe désormais, capable de démontrer le problème. Cela modifie largement le contexte pour toute organisation conservant des installations vulnérables, surtout si celles-ci permettent un accès direct à leur interface d’administration depuis Internet.

La priorité doit être la mise à jour. Mais cet incident peut également servir de guide pour une revue approfondie des mesures de protection de l’infrastructure virtualisée.

Comment savoir si votre environnement Proxmox VE est susceptible d’être affecté

La première erreur serait de réduire le problème à « Proxmox 7 et versions antérieures ».

Le composant concerné par cette faille est :

libpve-access-control >= 7.0-7 et < 8.0.4

Ce qui correspond approximativement à Proxmox VE 7.0-7.4 et à la version initiale de Proxmox VE 8.0, mais il est plus précis de vérifier le paquet installé plutôt que de se baser uniquement sur la version globale de la plateforme.

Depuis la console, la version peut être consultée avec :

pveversion -v

Il est également possible de vérifier spécifiquement le paquet concerné :

dpkg -l libpve-access-control

Si votre environnement utilise une branche ancienne, la prochaine étape est de déterminer si celle-ci est toujours sous support.

Proxmox VE 7 a atteint la fin de son support en juillet 2024. Maintenir une plateforme de virtualisation hors support pose un problème non seulement pour CVE-2023-54391, mais aussi pour toutes futures vulnérabilités : celles-ci n’auront pas de correctifs officiels pour des versions non maintenues.

Pour une installation concernée, la solution adéquate n’est pas simplement de masquer le port vulnérable. Il faut mettre à jour vers une version supportée de Proxmox VE, en suivant la procédure recommandée par le fournisseur, en vérifiant la compatibilité, les dépôts, le stockage, le cluster, et les sauvegardes.

Le port 8006 ne doit pas être accessible à tout Internet

Proxmox VE utilise généralement le TCP 8006 pour son interface web et son API d’administration.

Un test simple depuis l’extérieur du réseau d’entreprise permet de vérifier si l’interface répond via une adresse IP publique. Il faut également examiner le pare-feu périmétrique, les règles NAT et toutes les publications sur routeurs ou dispositifs de sécurité.

Le fait que Proxmox nécessite une connectivité n’autorise pas à laisser l’interface d’administration exposée publiquement.

Il est essentiel de différencier les réseaux utilisés par les machines virtuelles et celui de gestion de l’hyperviseur.

Une architecture d’entreprise raisonnable peut séparer, selon la taille et les besoins, le trafic utilisateur et applicatif, le stockage, le cluster, les migrations, et la gestion.

L’accès à l’interface administrative doit se limiter aux réseaux autorisés.

Une solution courante consiste à utiliser une VLAN ou réseau privé dédié à la gestion. Les administrateurs y accèdent via une VPN d’entreprise ou depuis des machines préalablement autorisées.

Une autre option est d’employer un bastion host ou système de saut (jump host) : une machine contrôlée agissant comme point d’entrée vers les systèmes administratifs.

Le pare-feu doit assurer cette séparation.

Au lieu d’un accès direct comme :

Internet → TCP 8006 → Proxmox VE

l’architecture doit plutôt envisager une approche du type :

Administrateur → VPN/réseau d’entreprise → réseau privé de gestion → Proxmox VE

Les machines virtuelles ne nécessitent pas forcément le même chemin : un serveur web hébergé sur Proxmox peut ouvrir les ports 80 et 443 vers Internet, tout en maintenant la gestion du nœud complètement séparée.

C’est cette séparation entre services publics et administration qui limite l’impact d’éventuelles vulnérabilités comme CVE-2023-54391.

Que faire en plus après mise à jour de Proxmox ?

Mettre à jour doit être la première étape en cas de vulnérabilité connue, mais un environnement virtualisé doit aussi comporter plusieurs couches de protection.

L’une d’elles est l’authentification multifactor (MFA) pour les comptes d’administration. Dans le cas précis de CVE-2023-54391, que certaines connexions n’aient pas de second facteur est particulièrement critique.

Il est aussi conseillé de revoir l’ensemble des comptes existants, en supprimant ceux qui ne sont plus utilisés. Les comptes d’administrateur doivent être accordés uniquement aux personnes ou services qui en ont réellement besoin.

Les règles de pare-feu doivent aussi être vérifiées. Ce n’est pas suffisant de vérifier le pare-feu local de Proxmox si un dispositif périphérique expose directement le service. Les règles NAT, les listes de contrôle d’accès, et tout paramètre hérité ou migré doivent être passés en revue.

Les logs peuvent également fournir des renseignements précieux. Proxmox utilise notamment des services comme pveproxy et pvedaemon, dont les événements peuvent être consultés avec :

journalctl -u pveproxy

journalctl -u pvedaemon

Dans un contexte où une intrusion est suspectée, il faut étendre la revue aux authentifications, comptes, modifications administratives, machines virtuelles, tâches planifiées, clés SSH, etc. Mettre à jour un serveur déjà compromis ne supprime pas nécessairement toutes les actions précédentes d’un attaquant.

Aussi, il est conseillé d’avoir des sauvegardes indépendantes du cluster. La haute disponibilité de Proxmox permet de restaurer certains services en cas de défaillance d’un nœud, mais ne remplace pas une stratégie de sauvegarde.

Il faut aussi faire la distinction entre snapshots et réplication : ce sont deux outils différents, et ils ne doivent pas être considérés comme des sauvegardes automatiques face à toutes formes d’attaques.

La philosophie est la même pour VMware vCenter

CVE-2023-54391 concerne Proxmox, mais l’architecture de sécurité permettant de limiter son exposition s’applique également à VMware vCenter.

vCenter offre une position privilégiée dans l’environnement VMware, pouvant intervenir sur les hôtes ESXi, les machines virtuelles, les permissions, réseaux et autres composantes de l’infrastructure.

C’est pourquoi il ne devrait pas être accessible directement depuis Internet sauf nécessité exceptionnelle, et architecture bien pensée.

Broadcom recommande de restreindre l’accès à vCenter via des adresses IP ou sous-réseaux autorisés. En environnement professionnel, il est préférable que vCenter et les hôtes ESXi résident dans des réseaux contrôlés.

La même recommandation s’applique pour les stockage, interfaces IPMI, iDRAC ou iLO, systèmes de sauvegarde, commutateurs, firewalls, et toute console capable de modifier l’infrastructure.

Une question essentielle pour faire l’inventaire :

Quelles interfaces d’administration de votre environnement peuvent actuellement être atteintes depuis une IP publique ?

Si vous voyez apparaître Proxmox, vCenter, contrôleurs de serveur ou outils de gestion de baies, il est légitime de vérifier pourquoi.

Migrer de VMware à Proxmox : une opportunité pour renforcer la sécurité

De nombreuses entreprises explorent actuellement une migration de VMware vers Proxmox VE. Ce changement ne doit pas se limiter à déplacer des machines virtuelles, mais aussi permettre de repenser l’architecture de sécurité.

Ce passage offre l’occasion de redéfinir la segmentation réseau, de mettre en place une authentification multifactorielle, de revoir la stratégie de firewall, de vérifier le stockage partagé, d’optimiser la configuration du cluster et de planifier une stratégie solide de sauvegarde et récupération après sinistre.

Cela évite aussi une pratique encore courante dans certaines petites installations : donner une adresse IP publique au hyperviseur pour en faciliter la gestion à distance, ce qui est risqué.

Une meilleure approche consiste à utiliser une VPN, un réseau privé connecté aux bureaux, ou un système d’accès administratifs contrôlé, évitant ainsi d’exposer directement l’interface de gestion.

Et cette stratégie sera encore pertinente après avoir corrigé CVE-2023-54391.

Guide rapide pour renforcer la sécurité d’un environnement Proxmox VE

Une vérification basique doit inclure la version de Proxmox et du paquet libpve-access-control, la mise à jour vers une version supportée, la vérification que le port TCP 8006 n’est pas accessible globalement, la migration vers un réseau privé pour l’administration, la limitation des accès via pare-feu et VPN, l’activation de la MFA pour les administrateurs, ainsi que la suppression des comptes inutiles.

Il est également crucial d’examiner les logs d’authentification et d’administration, de segmenter si nécessaire les réseaux de gestion, de cluster, et de stockage, de protéger l’accès à l’interface physique du matériel, et de maintenir des sauvegardes indépendantes et testées.

Aucune configuration ne peut garantir l’élimination totale des vulnérabilités futures. La véritable force réside dans la réduction du nombre de vecteurs d’attaque exploitables par des adversaires.

Avec la suppression progressive des versions obsolètes, CVE-2023-54391 finira par disparaître, mais d’autres vulnérabilités apparaîtront dans Proxmox, VMware, systèmes d’exploitation, stockage et équipements réseau.

La meilleure préparation n’est pas simplement d’attendre le correctif : c’est de s’assurer que, lorsque la faille sera corrigée, votre environnement ne sera pas exposé publiquement à tout Internet.

Questions fréquentes

Comment vérifier si Proxmox VE est affecté par CVE-2023-54391 ?

Il faut surtout vérifier la version de libpve-access-control. La plage affectée commence à 7.0-7 et se termine avant la version 8.0.4 ; la commande pveversion -v fournit un état détaillé des composants installés.

Est-il dangereux de laisser le port 8006 de Proxmox ouvert à Internet ?

Ce n’est pas une configuration recommandée en milieu professionnel. Il est préférable de garder l’interface administrateur dans un réseau privé, accessible via VPN, réseaux de confiance ou un serveur de saut.

Une simple mise à jour de Proxmox suffit-elle à tout régler ?

Mettre à jour corrige la vulnérabilité connue, mais il faut aussi profiter de l’incident pour examiner l’exposition publique, le pare-feu, la MFA, les comptes administratifs et les journaux. En cas d’indices de compromission, une mise à jour seule ne garantit pas qu’un environnement est sécurisé.

Que vérifier lors d’une migration de VMware vers Proxmox ?

Outre les machines virtuelles et la compatibilité, il faut vérifier la segmentation réseau, le stockage, la haute disponibilité, la sauvegarde, la récupération après sinistre, le pare-feu, la MFA, et l’accès distant. La migration est également une opportunité pour éviter que la nouvelle console d’administration ne soit directement exposée à Internet.

Sources :

• Proxmox Server Solutions, PSA-2026-00043-1, note concernant la faille d’authentification dans d’anciennes versions de Proxmox VE.
• Proxmox VE Administration Guide, documentation sur la gestion, le pare-feu et l’accès à l’interface web.
• CVE-2023-54391, détails de la vulnérabilité et évaluation CVSS.
• Broadcom, documentation sur la sécurité et la restriction d’accès administratif à VMware vCenter Server.