LXD et MicroCloud : faille CVSS 10 sans mot de passe

Ce qui s'est passé

Canonical a publié fin octobre 2026 un avis de sécurité critique concernant CVE-2026-112816, une vulnérabilité de contournement d'authentification affectant ses produits LXD et MicroCloud. La faille a été notée CVSS 4.0 10.0 — le score maximum possible — ce qui en fait l'une des vulnérabilités les plus sévères révélées sur ces plateformes depuis leur création.

LXD est le gestionnaire de conteneurs système et de machines virtuelles de Canonical, largement déployé dans les infrastructures Linux d'entreprise pour la virtualisation légère. MicroCloud est son orchestrateur distribué, conçu pour créer des clusters d'infrastructure convergée à partir de nœuds LXD. Les deux produits sont massivement utilisés dans les environnements de cloud privé, d'hébergement mutualisé et de laboratoires de développement.

Techniquement, la faille réside dans le mécanisme de validation des certificats clients lors des connexions HTTPS vers l'API de gestion de LXD. Pour sécuriser les communications entre les clients d'administration et le daemon, LXD implémente une authentification mutuelle TLS (mTLS) : le serveur présente son certificat, et le client doit présenter le sien, préalablement enregistré comme client de confiance. C'est ce second volet qui est défaillant.

Selon les analyses publiées par Rescana, SOC Prime et Threatening Defence, la vulnérabilité provient du fait que le serveur LXD comparait chaque certificat présent dans la chaîne de certificats fournie par le client contre son magasin de confiance, plutôt que de vérifier uniquement le certificat final de la chaîne. Un attaquant peut ainsi construire une chaîne de certificats contenant le certificat public d'un client légitime (qu'il peut obtenir sans avoir besoin de la clé privée correspondante) et se voir accorder les mêmes droits que ce client autorisé.

La condition préalable est que l'attaquant doit pouvoir joindre le port HTTPS de l'API LXD. Dans une installation LXD autonome standard, cette API n'est pas exposée réseau par défaut. Cependant, dans les déploiements MicroCloud, les nœuds communiquent entre eux via cette API, ce qui augmente significativement la surface d'attaque dans les clusters multi-nœuds. De même, tous les déploiements ayant activé l'accès réseau à l'API pour des besoins d'administration distante sont directement exposés.

Un proof-of-concept public a été développé et rendu disponible, ce qui abaisse considérablement la barrière d'entrée pour d'éventuels attaquants. D'après l'évaluation publiée par la CISA le 30 octobre, aucune exploitation active n'avait encore été détectée à cette date, mais la disponibilité d'un PoC rend l'exploitation imminente probable.

Canonical a publié des versions corrigées pour l'ensemble des branches maintenues : LXD 6.10.1, 5.21.9, 5.0.11 et 4.0.15 ; MicroCloud 3.4.1 et 2.1.5. Le projet Incus, un fork communautaire de LXD, a également été affecté (même CVE référencé sous GHSA-xg75-xf37-cph9) et corrigé dans sa version 7.6.0. La mise à jour s'effectue via les commandes snap : sudo snap refresh lxd et sudo snap refresh microcloud sur chaque nœud du cluster.

Aucune mesure d'atténuation alternative (pare-feu applicatif, configuration) ne permet de corriger la faille sans appliquer le patch. La seule protection partielle consiste à restreindre l'accès réseau au port HTTPS de l'API aux seules adresses IP légitimes, mais cette mesure ne supprime pas la vulnérabilité sous-jacente.

Pourquoi c'est important

Une faille CVSS 10.0 sur LXD touche au cœur de la sécurité des infrastructures de cloud privé déployées sur Linux. LXD étant le socle technique de nombreuses offres d'hébergement cloud, de plateformes VPS et d'environnements de développement distribués, la surface d'attaque potentielle est considérable. Un attaquant exploitant CVE-2026-112816 peut prendre le contrôle complet de l'hyperviseur, accéder à tous les conteneurs et machines virtuelles hébergés, et pivoter vers d'autres systèmes du réseau interne.

Le mécanisme d'exploitation est particulièrement insidieux car il ne nécessite pas de clé privée volée ni de credential compromis. Il suffit de connaître le certificat public d'un client autorisé — information qui peut être obtenue par plusieurs vecteurs, notamment en interceptant du trafic TLS non protégé ou en accédant à des fichiers de configuration client. Cela rend la détection préventive difficile : un attaquant préparant cet exploit ne laisse aucune trace de vol de credential dans les journaux.

Pour les entreprises utilisant des architectures de cloud hybride ou privé basées sur LXD/MicroCloud, cet incident souligne l'importance d'un processus de gestion des vulnérabilités réactif. Les environnements déployés via snap bénéficient de la possibilité de mises à jour automatiques, mais de nombreux déploiements en production ont ces mises à jour automatiques désactivées pour des raisons de stabilité. Les équipes d'infrastructure doivent traiter cette mise à jour comme une priorité urgente.

Du côté réglementaire, sous NIS2 et DORA, les opérateurs d'infrastructures critiques utilisant LXD ont l'obligation de déployer des correctifs de sécurité critiques dans des délais stricts. La disponibilité d'un PoC public renforce l'urgence : toute organisation tardant à patcher s'expose non seulement à un risque technique élevé, mais aussi à un risque de non-conformité si un incident survient après la publication du correctif.

Ce qu'il faut retenir

• Mettez à jour LXD vers 6.10.1, 5.21.9, 5.0.11 ou 4.0.15 selon votre branche, et MicroCloud vers 3.4.1 ou 2.1.5 — un PoC public existe, l'exploitation est imminente.
• Vérifiez si votre API LXD est exposée réseau et restreignez l'accès aux seules IP de gestion légitimes dans l'attente du patch sur les systèmes critiques.
• Auditez les journaux d'accès à l'API LXD depuis le 28 octobre pour détecter tout accès inhabituel via des chaînes de certificats anormales.