Failles Proxmox VE - usurpation d’identité et risque d’accès root depuis un conteneur

Deux failles Proxmox® VE, détaillées dans les bulletins du 2 novembre 2026, concernent les accès et les conteneurs : une usurpation d’identité dans un même domaine d’authentification et un risque d’exécution de code comme root sur l’hôte lors de certaines opérations sur un conteneur actif. Source : bulletins officiels Proxmox.

La priorité est de vérifier les paquets de chaque nœud et d’appliquer les mises à jour de sa branche. La maintenance d’une plateforme de virtualisation couvre aussi ses outils d’administration, au-delà du noyau et des systèmes invités.

Une identité interprétée différemment dans un ticket

L’avis PSA-2026-00081-1 porte sur une incohérence d’encodage des noms d’utilisateurs dans les tickets. L’attaque suppose de pouvoir créer des utilisateurs dans le domaine concerné, ou d’agir sur une source OIDC, LDAP ou Active Directory acceptant certains caractères dans les identifiants. Bulletin Proxmox sur les tickets.

Un domaine d’authentification, ou realm, définit la source auprès de laquelle Proxmox VE vérifie l’identité. Il peut s’agir de comptes gérés par la plateforme ou d’un annuaire externe. La délégation de création des comptes et les règles de l’annuaire font donc partie de la sécurité des accès. Documentation officielle des utilisateurs et domaines.

Le journal de libpve-common-perl explique le défaut : un nom contenant une séquence d’échappement pouvait être interprété autrement lors de la vérification du ticket. L’identité enregistrée et celle reconnue à la lecture ne correspondaient plus. La version 9.2.5 corrige l’encodage ; 9.2.6 ajoute le rejet d’anciens tickets contenant des échappements inattendus et peut demander aux utilisateurs concernés de se reconnecter. Changelog officiel de libpve-common-perl.

Notre recommandation est de revoir les droits de création des utilisateurs et les identités provenant des annuaires, en complément du correctif. Un accès d’administration restreint et des permissions limitées réduisent le nombre de chemins à surveiller au quotidien.

Un conteneur actif peut perturber une opération de l’hôte

L’avis PSA-2026-00082-1 vise une course entre le contrôle d’un chemin et son utilisation par pct mount ou pct fstrim. Un attaquant présent dans le conteneur peut modifier sa hiérarchie de montage pendant l’opération. Le scénario peut conduire à monter des répertoires contrôlés sur des chemins de l’hôte, puis à une exécution de code privilégiée. Bulletin Proxmox sur les montages.

Ce type de défaut est appelé TOCTOU : une vérification est correcte à un instant donné, mais ce qu’elle vient de vérifier change avant l’action suivante. Ici, le logiciel doit s’assurer que le répertoire utilisé est toujours celui qui a été contrôlé.

Le journal de pve-container décrit le durcissement : les volumes sont attachés au répertoire déjà vérifié, au lieu de résoudre à nouveau un chemin susceptible d’avoir changé. Changelog officiel de pve-container.

Les conteneurs Proxmox VE reposent sur LXC et partagent le noyau de l’hôte. Leur isolation dépend aussi des opérations que la plateforme réalise pour eux. Une mise à jour effectuée uniquement à l’intérieur du conteneur laisse les outils de gestion de l’hôte hors de la maintenance. Documentation officielle des conteneurs.

Quels paquets mettre à jour ?

Les seuils indiqués dans les avis sont les suivants :

Bulletin	Paquet de l’hôte	Correction annoncée à partir de
PSA-2026-00081-1	libpve-common-perl	9.2.5
PSA-2026-00082-1	pve-container	6.1.15

Référence : versions correctives publiées par Proxmox.

Retenez la version à jour fournie pour votre branche, plutôt que de vous arrêter au premier seuil corrigé. Le complément de libpve-common-perl sur les anciens tickets l’illustre bien. Les journaux de paquets peuvent aussi précéder la publication du bulletin : la date de l’alerte ne correspond pas nécessairement au début de disponibilité du code corrigé.

Ces références ne constituent pas une matrice de toutes les anciennes versions. Pour un parc hétérogène, rapprochez chaque hôte de sa branche, de ses dépôts et des informations de l’éditeur. N’installez pas isolément un paquet d’une autre branche pour atteindre un numéro.

Vérifier chaque nœud sans tenter d’exploiter les failles

Sur l’hôte Proxmox VE, relevez les versions de la plateforme :

pveversion -v

Puis contrôlez les deux paquets ciblés :

dpkg-query -W -f='${binary:Package}\t${Version}\t${db:Status-Status}\n' libpve-common-perl pve-container

Pour consulter les versions candidates connues localement par APT :

apt-cache policy libpve-common-perl pve-container

La version candidate dépend des dépôts configurés et de la dernière actualisation de leurs index. Un cluster n’est pas vérifié parce qu’un seul nœud est à jour. Conservez le résultat pour chaque serveur et reprenez les contrôles après intervention.

Nous recommandons ensuite une séquence simple :

1. Inventorier les accès et les charges : domaines d’authentification, délégations, conteneurs et services critiques.
2. Préparer la maintenance : accès de secours, sauvegardes exploitables, état du cluster et capacité restante.
3. Appliquer les mises à jour avec le parcours prévu pour la branche Proxmox VE utilisée.
4. Valider leur prise en compte : versions installées, éventuels services à relancer, connexion à l’administration et tâches courantes.
5. Contrôler le fonctionnement métier, puis documenter le résultat sur l’ensemble du parc.

Une mise à jour de bibliothèque et une mise à jour de noyau ne se valident pas de la même manière. Préparez les relances nécessaires selon les paquets installés ; si un noyau est également corrigé pendant l’intervention, vérifiez celui qui est réellement chargé après redémarrage. Nous détaillons cette organisation dans notre article sur les correctifs Linux et la maintenance des clusters Proxmox VE.

La sécurité de la virtualisation se joue aussi dans l’exploitation

Les accès aux annuaires, les droits des équipes et les outils de gestion des conteneurs font partie du même périmètre de responsabilité. Une plateforme peut héberger des applications à jour tout en accumulant du retard sur les composants qui les administrent.

L’objectif est concret : savoir ce qui tourne, qui peut agir et comment appliquer les correctifs sans improviser l’intervention. C’est ce suivi qui rend les alertes suivantes plus faciles à traiter.

Forget About IT, Proxmox Authorized Reseller, accompagne la conception, la maintenance et l’exploitation de ces environnements. Découvrez notre accompagnement Proxmox VE et notre offre d’infogérance de serveurs Linux pour inscrire ces vérifications dans le fonctionnement régulier de votre infrastructure.

Sources

• Proxmox - PSA-2026-00081-1, usurpation d’identité via l’encodage des tickets.
• Proxmox - PSA-2026-00082-1, course lors du montage de conteneurs actifs.
• Proxmox - journal officiel de libpve-common-perl.
• Proxmox - journal officiel de pve-container.
• Proxmox - documentation des identités et des domaines d’authentification.
• Proxmox - documentation des conteneurs.

FAQ - corriger les hôtes Proxmox VE

Quels paquets vérifier sur les hôtes Proxmox VE ?

Contrôlez libpve-common-perl et pve-container sur chaque nœud. Installez les mises à jour de votre branche depuis les dépôts Proxmox VE, puis vérifiez les versions et les services concernés.

Mettre à jour les systèmes des conteneurs suffit-il ?

Non. La maintenance doit aussi couvrir les outils de gestion installés sur l’hôte Proxmox VE. Corriger uniquement les applications et les distributions des invités ne couvre pas ce périmètre.