Une faille critique dans LXD et MicroCloud permet un accès root sans clés privées

Canonical a publié des correctifs d'urgence pour une faille de sécurité critique affectant son hyperviseur de conteneurs LXD et son outil de clustering MicroCloud. La vulnérabilité, identifiée sous la référence CVE-2026-112816, présente un score de sévérité maximale de 10.0 sur le système Common Vulnerability Scoring System (CVSS). Elle permet à des attaquants distants d'usurper l'identité de clients fiables et d'accéder sans autorisation à l'infrastructure, sans posséder les clés cryptographiques privées nécessaires.

Ce qui s'est passé

La faille permet à un attaquant de se connecter en tant que client fiable en exploitant une erreur de vérification dans le processus d'authentification TLS mutuelle. Pour réussir, l'attaquant doit avoir un accès réseau à l'API HTTPS et disposer du certificat public d'un client déjà reconnu comme fiable par le serveur. Une fois authentifié, l'attaquant agit en tant que ce client, obtenant un accès complet au cluster et à ses machines virtuelles. Si le compte usurpé détient des droits privilégiés, l'attaquant peut escalader ses privilèges jusqu'à obtenir un accès root sur la machine hôte elle-même.

Ce problème a été initialement signalé par le projet Incus, un fork communautaire de LXD, qui a confirmé que le bug affectait les deux plateformes. Bien que les paquets standard de LXD dans l'archive Ubuntu ne soient pas concernés, les utilisateurs exécutant LXD ou MicroCloud via des paquets Snap sont exposés au risque. Canonical a déclaré qu'il n'y a aucune preuve que cette vulnérabilité ait été exploitée dans la nature, et elle n'apparaît actuellement pas sur la liste des vulnérabilités connues exploitées de la CISA. Cependant, l'impact potentiel est suffisamment grave pour justifier une attention immédiate de la part des équipes d'infrastructure.

Comment cela fonctionne

LXD et MicroCloud utilisent le TLS mutuel (mTLS) pour sécuriser l'accès API distant. Dans cette configuration, un client prouve son identité en présentant un certificat numérique. Le serveur vérifie ce certificat contre un magasin de confiance, qui contient les identités de tous les clients autorisés. La vulnérabilité réside dans la manière dont le serveur valide la chaîne de certificats lors de cet échange initial.

Dans une connexion TLS standard, le protocole ne prouve cryptographiquement que le client possède la clé privée correspondant au premier certificat de la chaîne, connu sous le nom de certificat feuille (leaf certificate). Le reste de la chaîne est simplement des données attachées par le client. L'implémentation défaillante dans LXD comparait chaque certificat de la chaîne fournie avec le magasin de confiance, plutôt que de valider strictement le certificat feuille. Un attaquant pouvait prendre le certificat public d'un client fiable, qui n'est pas secret, et l'attacher à sa propre chaîne. Le serveur accepterait alors à tort l'attaquant comme étant le client fiable car il trouvait une correspondance dans la chaîne, même si l'attaquant ne possédait pas la clé privée correspondante pour ce certificat spécifique.

Détails clés

• ID de la vulnérabilité : CVE-2026-112816 avec un score CVSS de 10.0.
• Produits affectés : Versions LXD 4.0.14, 5.0.10, 5.21.8 et 6.9, ainsi que les clusters MicroCloud.
• Versions corrigées : LXD 6.10.1, 5.21.9, 5.0.11, 4.0.15, et MicroCloud 3.4.1 ou 2.1.5 via les canaux Snap.
• Conditions d'attaque : Accès réseau à l'API HTTPS et possession du certificat public d'un client fiable.
• Origine : Signalé par le projet Incus, qui a publié son propre correctif dans la version 7.6.0.
• Statut de l'exploitation : Aucune exploitation active connue ni code d'exploit public n'existe au 30 octobre 2026.

Pourquoi c'est important

Pour les ingénieurs gérant des infrastructures conteneurisées, cette vulnérabilité compromet le modèle de confiance fondamental du mTLS. Le TLS mutuel est souvent considéré comme un mécanisme d'authentification fort car il exige la possession d'une clé privée. Cette faille contourne entièrement cette exigence, signifiant que le simple fait de posséder un certificat public, souvent distribué ouvertement ou capturé lors de l'intégration au réseau, suffit pour usurper l'identité. Cela est particulièrement dangereux pour les environnements MicroCloud, où un attaquant qui capture le certificat public d'un membre lors du processus d'intégration au cluster peut ensuite usurper l'identité de ce membre.

L'impact va au-delà du simple accès aux données. Comme LXD gère des conteneurs au niveau système, une usurpation réussie d'un client privilégié peut conduire à une compromission totale de l'hôte. Cela donne à l'attaquant un accès root à la machine physique ou virtuelle sous-jacente, lui permettant de s'échapper entièrement de l'environnement conteneurisé. Pour les équipes utilisant LXD en production, surtout celles exposant l'API sur un réseau, cela représente une défaillance critique du contrôle d'accès qui ne peut pas être atténuée par des modifications de configuration seules.

Ce que vous pouvez faire

• Mettez à jour immédiatement vos installations LXD et MicroCloud en utilisant sudo snap refresh lxd et sudo snap refresh microcloud.
• Vérifiez la version installée après la mise à jour, car les correctifs peuvent être déployés progressivement des canaux candidats vers les canaux stables.
• Restreignez l'accès réseau au listener de l'API LXD si vous ne pouvez pas mettre à jour immédiatement, car l'attaque nécessite un accès direct à l'API HTTPS.
• Vérifiez si votre serveur LXD autonome a activé core.https_address ; sinon, il est probablement non exposé à ce vecteur d'attaque à distance spécifique.
• Surveillez toute activité inhabituelle dans l'appartenance au cluster ou les journaux API qui pourrait indiquer une tentative d'usurpation d'identité.
• Si vous utilisez Incus au lieu de LXD, effectuez une mise à niveau vers la version 7.6.0 ou ultérieure pour corriger ce problème ainsi que 17 autres failles de sécurité.