CVE-2026-112816 : faille critique LXD et MicroCloud, accès root au cluster sans authentification

Le 28 octobre 2026, Canonical a publié un avis de sécurité concernant CVE-2026-112816, une faille critique notée 10.0 sur 10 (CVSS v4.0) dans la validation des certificats TLS de LXD et MicroCloud. Un attaquant non authentifié peut exploiter cette vulnérabilité pour se faire passer pour n'importe quel client de confiance du cluster et obtenir un accès complet à l'API, aux machines virtuelles et aux conteneurs LXC. Selon le niveau de privilèges du client usurpé, l'attaquant peut obtenir un accès root à l'hôte, compromettant l'ensemble de l'infrastructure de virtualisation. Les correctifs sont disponibles depuis le 29 octobre 2026 : tout administrateur gérant une installation LXD ou MicroCloud exposée sur le réseau doit appliquer la mise à jour sans attendre.

Source : avis de sécurité officiel de Canonical (28 octobre 2026). Référence GitHub : GHSA-99jp-jwmc-65p4.

Qui est concerné par CVE-2026-112816

Tout administrateur qui utilise LXD pour héberger des conteneurs LXC ou des machines virtuelles sur un serveur dédié ou un VPS Linux est directement concerné. LXD est la solution de virtualisation par conteneurs de Canonical, installée par défaut sur Ubuntu et disponible via Snap sur Debian et d'autres systèmes Unix. Les profils les plus exposés sont :

• Les administrateurs de serveurs dédiés qui utilisent LXD pour isoler des services dans des conteneurs ou des machines virtuelles séparés : serveur web Apache ou Nginx, bases de données MySQL ou PostgreSQL, serveurs DNS, serveurs de jeu, scripts de traitement par lots ;
• Les hébergeurs et fournisseurs d'infrastructure qui proposent des serveurs virtuels ou de l'hébergement mutualisé à leurs clients via des conteneurs LXD, chaque conteneur disposant de ses propres ressources (RAM, CPU, stockage, adresse IP) ;
• Les équipes DevOps et les administrateurs de clusters MicroCloud qui pilotent des environnements de virtualisation multi-noeuds depuis un poste d'administration distant connecté à l'API REST.

Si votre serveur dédié ou votre VPS exécute le daemon LXD et expose son API sur le réseau (port 8443 par défaut), la migration vers la version corrigée est urgente. Tous les conteneurs et toutes les machines virtuelles hébergés sur ce serveur sont accessibles à un attaquant exploitant cette faille, y compris ceux qui hébergent des sites web, des bases de données ou des scripts d'automatisation.

Ce que cette faille change pour l'administration de votre serveur

LXD est l'hyperviseur de conteneurs et de machines virtuelles le plus répandu sur les serveurs dédiés et les VPS Linux Ubuntu. Il permet de créer, configurer et administrer des conteneurs LXC et des VM depuis une API REST sécurisée par un certificat SSL/TLS avec authentification par certificat client. MicroCloud s'appuie sur LXD pour orchestrer des clusters de virtualisation multi-noeuds, facilitant le déploiement de machines virtuelles et de conteneurs à grande échelle.

Avec CVE-2026-112816, cette authentification TLS ne protège plus rien. Un attaquant qui possède le certificat public d'un utilisateur de confiance (information non secrète, souvent disponible dans les dépôts de configuration ou échangée entre noeuds du cluster) peut l'injecter dans sa propre chaîne de certificats et être reconnu comme cet utilisateur. LXD comparait tous les certificats de la chaîne TLS du client avec son trust store, sans vérifier que seul le certificat feuille prouve la possession de la clé privée correspondante.

En pratique, cela signifie qu'un attaquant ayant accès au réseau du cluster LXD peut :

• Lister, créer, modifier ou supprimer des conteneurs LXC et des machines virtuelles ;
• Exécuter des commandes shell dans n'importe quel conteneur ou VM existant ;
• Accéder aux volumes de stockage, aux images et aux snapshots ;
• Modifier la configuration des ressources allouées (RAM, CPU, stockage) aux environnements virtuels ;
• Si le client usurpé a des privilèges admin : obtenir un accès root complet à la machine hôte et compromettre l'ensemble de l'infrastructure de virtualisation.

Versions touchées et correctifs disponibles

Toutes les branches de LXD maintenues sont affectées, de la branche LTS 4.0 à la branche stable 6.x. Le tableau ci-dessous résume les versions vulnérables et les correctifs publiés le 29 octobre 2026 :

LXD et MicroCloud sont distribués via Snap sur Ubuntu et Debian. La migration vers la version corrigée se fait en une commande depuis un shell :

sudo snap refresh lxd
sudo snap refresh microcloud

Vérifiez la version installée après la mise à jour :

snap info lxd | grep installed
snap info microcloud | grep installed

Sur les systèmes Debian où LXD est installé via Snap (le paquet natif lxd des dépôts Debian a été retiré au profit du Snap depuis Debian 12), la même commande snap refresh s'applique. Si vous avez compilé LXD depuis les sources, récupérez le code corrigé depuis le dépôt GitHub officiel de Canonical et reconstruisez le binaire.

Comment fonctionne la vulnérabilité

L'API REST de LXD utilise le protocole TLS avec authentification mutuelle par certificat SSL/TLS. Chaque client autorisé (outil lxc en ligne de commande, script d'automatisation, noeud distant du cluster) possède un certificat ajouté au trust store du serveur LXD. Lors d'une connexion, le serveur vérifie que le certificat présenté correspond à une entrée connue.

Le problème se situe dans la logique de vérification : LXD comparait tous les certificats de la chaîne TLS (certificat feuille et certificats intermédiaires) avec le trust store, au lieu de vérifier uniquement le certificat feuille. C'est une erreur de validation classique, répertoriée sous CWE-295 (Improper Certificate Validation).

Un attaquant peut donc :

1. Récupérer le certificat public d'un client de confiance (ce certificat n'est pas un secret : il peut être exposé dans un dépôt de configuration, un script partagé ou un backup non chiffré) ;
2. Générer sa propre paire de clés et son propre certificat feuille ;
3. Placer le certificat public de la victime comme certificat intermédiaire dans sa chaîne TLS ;
4. Se connecter à l'API LXD depuis un shell distant : le serveur trouve le certificat de la victime dans la chaîne, le reconnaît dans son trust store, et accorde l'accès.

Le serveur ne vérifie jamais que le client possède réellement la clé privée associée au certificat de confiance. Seul le certificat feuille prouve cette possession via le handshake TLS, mais LXD ne limitait pas sa vérification à ce certificat. Cette faille a été identifiée à partir du projet Incus (le fork communautaire de LXD) et signalée à Canonical.

Vérifier, sauvegarder et patcher votre installation

Si vous utilisez LXD sur un serveur dédié ou un VPS Linux, suivez ces étapes dans l'ordre pour appliquer le correctif en toute sécurité.

1. Vérifier la version installée

lxd version
snap info lxd | grep installed

Si la version affichée correspond à une version vulnérable du tableau ci-dessus, poursuivez immédiatement.

2. Effectuer un backup de la configuration LXD

Avant toute migration de version, sauvegardez la configuration complète de votre instance LXD, y compris le trust store, les profils réseau et les scripts de démarrage. Ce backup permet de restaurer un état fonctionnel si la mise à jour provoque un problème inattendu :

sudo lxd shutdown
sudo cp -a /var/snap/lxd/common/lxd /var/snap/lxd/common/lxd-backup-$(date +%Y%m%d)
sudo lxd activateifneeded

Pour un backup complet incluant les données des conteneurs et des machines virtuelles, consultez notre guide sur les sauvegardes et la haute disponibilité sur serveur dédié. Envisagez aussi de chiffrer vos sauvegardes et les stocker hors site pour les protéger en cas de compromission complète du serveur.

3. Appliquer le correctif

sudo snap refresh lxd --channel=6/stable

Adaptez le canal (5.21/stable, 5.0/stable ou 4.0/stable) selon votre branche. Vérifiez ensuite la version active :

lxd version

4. Auditer les accès récents

Après la mise à jour, examinez les journaux du daemon LXD pour détecter des connexions suspectes depuis des adresses IP inconnues :

sudo journalctl -u snap.lxd.daemon --since "2026-10-25" --no-pager | head -200

Recherchez les connexions inhabituelles, les créations de conteneurs ou de machines virtuelles que vous n'avez pas initiées, et les exécutions de commandes inattendues dans les conteneurs existants. Si vous repérez une activité suspecte, considérez l'ensemble du cluster comme potentiellement compromis : changez les certificats du trust store, inspectez les conteneurs et les VM, et vérifiez l'intégrité du système hôte.

Configurer le pare-feu pour isoler l'API LXD

Le correctif corrige la validation des certificats SSL/TLS, mais la meilleure défense en profondeur consiste à ne jamais exposer l'API LXD au-delà du strict nécessaire. Par défaut, le daemon LXD écoute sur le port 8443. Configurez votre firewall pour restreindre l'accès à ce port aux seules adresses IP de vos noeuds de cluster et de vos postes d'administration distants.

Avec UFW (le firewall par défaut sur Ubuntu) :

sudo ufw deny 8443
sudo ufw allow from 10.0.0.0/24 to any port 8443 proto tcp
sudo ufw allow from 192.168.1.100 to any port 8443 proto tcp

Remplacez les adresses IP par celles de votre réseau de gestion. La première règle bloque tout accès distant au port 8443, les suivantes autorisent uniquement le sous-réseau du cluster et l'adresse IP de votre poste admin.

Avec nftables (le firewall moderne du noyau Linux, disponible sur Debian 12 et Ubuntu 22.04+) :

nft add rule inet filter input tcp dport 8443 ip saddr { 10.0.0.0/24, 192.168.1.100 } accept
nft add rule inet filter input tcp dport 8443 drop

Sur un cluster MicroCloud multi-noeuds, chaque noeud doit autoriser les adresses IP des autres noeuds. Documentez ces règles dans un script de configuration versionné pour pouvoir les reproduire lors d'une migration ou d'une réinstallation du serveur.

Renforcer la sécurité de votre infrastructure de virtualisation

Au-delà du correctif et de la configuration du firewall, cette vulnérabilité rappelle l'importance de plusieurs bonnes pratiques pour tout administrateur gérant des environnements de virtualisation LXD sur un serveur dédié :

• Auditer le trust store de LXD. Listez les certificats autorisés avec lxc config trust list et supprimez ceux qui ne sont plus nécessaires. Chaque certificat SSL/TLS dans le trust store est un vecteur d'accès potentiel.
• Configurer les mises à jour automatiques de sécurité. Sur Ubuntu et Debian, activez unattended-upgrades pour appliquer les correctifs de sécurité sans intervention manuelle de l'administrateur. Notre guide détaille la procédure : automatiser les mises à jour de sécurité sur VPS Ubuntu.
• Vérifier la chaîne TLS de vos services. Utilisez openssl s_client pour inspecter la validité des certificats exposés par vos services, y compris l'API LXD et les serveurs web hébergés dans vos conteneurs.
• Durcir l'accès SSH à vos serveurs hébergeant LXD : désactiver l'authentification par mot de passe, restreindre les utilisateurs autorisés et tracer les connexions avec auditd.
• Sauvegarder régulièrement. Un backup chiffré et stocké hors du serveur permet de restaurer un état sain en cas de compromission détectée tardivement.
• Surveiller les connexions avec un IDS. CrowdSec ou Fail2ban détectent les comportements suspects (scans de ports, tentatives d'accès répétées) et bloquent automatiquement les adresses IP malveillantes sur votre firewall.
• Isoler les environnements virtuels critiques. Si vous hébergez des services sensibles (bases de données, serveurs web, scripts de traitement) dans des conteneurs LXD, segmentez le réseau virtuel pour limiter la propagation latérale en cas de compromission d'un conteneur.

Questions fréquentes