LXD et MicroCloud : la faille CVE-2026-112816 corrigée

Canonical a corrigé le 29 octobre 2026 CVE-2026-112816, une faille critique notée CVSS 10,0, la note maximale, affectant LXD et MicroCloud, ses outils de virtualisation de conteneurs et de machines virtuelles largement utilisés par des hébergeurs et des équipes DevOps. Elle permet à un attaquant disposant d'un accès réseau à l'API de contourner l'authentification mutuelle par certificat TLS et de se faire passer pour un client, ou un membre de cluster, de confiance, sans posséder sa clé privée. Aucune exploitation active n'est signalée à ce jour selon Canonical et la CISA.

Qu'est-ce que CVE-2026-112816 ?

CVE-2026-112816 est une faille de contournement d'authentification dans le mécanisme TLS mutuel de LXD et MicroCloud. Pour s'authentifier, un client présente un certificat au serveur, qui le compare à sa liste de certificats autorisés. Selon l'avis de sécurité de Canonical, le serveur vérifiait chaque certificat de la chaîne présentée par le client, et non uniquement le certificat terminal (leaf) dont la possession de la clé privée est réellement prouvée par la poignée de main TLS.

Un attaquant peut donc construire son propre certificat terminal, prouver qu'il en détient la clé, puis ajouter à la chaîne le certificat public d'un client de confiance, que LXD accepte alors comme preuve d'identité de ce client. Le certificat public d'un client n'est pas un secret : il est échangé lors de toute poignée de main TLS et peut aussi être récupéré via l'API de certificats ou auprès d'un serveur déjà contacté par ce client. Dans un cluster MicroCloud, le même mécanisme permet d'usurper un membre en capturant son certificat public au moment où il rejoint le groupe. L'impact dépend des droits du client imité : Canonical indique qu'un attaquant peut obtenir un accès root à la machine hôte si ce client dispose de privilèges suffisants.

À retenir : l'exploitation nécessite un accès réseau à l'API HTTPS de LXD, qui n'est pas exposée par défaut (LXD écoute en standard sur un socket Unix local). Le risque concerne avant tout les déploiements où core.https_address a été configuré pour une administration à distance, et les clusters MicroCloud, par nature exposés entre leurs membres.

Versions concernées et correctifs

Les paquets Snap sont concernés ; les paquets Debian/Ubuntu « archive » de LXD ne le sont pas, ou ne sont plus proposés sur les versions listées par Canonical. Incus, le projet communautaire dérivé de LXD, est touché par la même faille et publie la version corrigée 7.6.0, sans contournement de configuration possible en attendant la mise à jour.

Comment se protéger ?

1. Mettre à jour immédiatement avec sudo snap refresh lxd et sudo snap refresh microcloud, puis vérifier la version réellement installée via snap list lxd microcloud : Canonical signale que les correctifs continuaient de migrer du canal candidat vers le canal stable au moment de la publication.
2. Vérifier l'exposition de l'API : un serveur LXD autonome n'expose pas l'API HTTPS par défaut. Si core.https_address a été activé pour une administration à distance, restreindre l'accès au port à une liste d'adresses IP de confiance en attendant la mise à jour.
3. Auditer les clusters MicroCloud en priorité : un membre dont le certificat public a pu être observé lors d'une jonction au cluster constitue le scénario d'usurpation le plus probable décrit par Canonical.
4. Mettre à jour Incus en 7.6.0 pour les déploiements utilisant ce fork communautaire, aucun contournement n'étant proposé par le projet.
5. Consulter le catalogue CVE pour suivre un éventuel passage de CVE-2026-112816 au statut KEV de la CISA, et le calculateur CVSS pour prioriser ce correctif selon votre exposition réelle.
6. Les principes de cloisonnement réseau qui s'appliquent à Docker, détaillés dans notre guide sur la sécurisation de Docker, valent tout autant pour un hôte LXD ou MicroCloud exposé.

L'avis du CSIRT

Un score CVSS de 10,0 impose un traitement en urgence, mais la priorité réelle dépend de l'exposition réseau de l'hôte. Un serveur LXD autonome resté sur son socket Unix local n'est pas exploitable à distance : la mise à jour planifiée dans la journée suffit. À l'inverse, un hôte avec core.https_address activé, ou tout cluster MicroCloud, doit être traité comme prioritaire absolu, surtout si des machines virtuelles ou conteneurs hébergés disposent de privilèges élevés sur l'hôte.

Le piège classique sur ce type de faille d'authentification est de considérer le correctif comme suffisant sans vérifier qu'il s'est réellement appliqué : Canonical précise lui-même que les paquets Snap mettaient du temps à migrer vers le canal stable, d'où l'intérêt de contrôler la version avec snap list plutôt que de se fier au message de succès du refresh. Côté détection, il n'existe pas de signature d'exploitation publique pour cette faille : en l'absence d'indicateur de compromission connu, la vigilance porte sur les connexions à l'API HTTPS depuis des adresses IP inhabituelles et sur l'apparition de clients ou de membres de cluster qui ne correspondent à aucune jonction légitime documentée. Après correctif, il reste utile de faire l'inventaire des certificats clients autorisés et de révoquer ceux qui ne sont plus nécessaires, pour réduire la surface de certificats potentiellement interceptables.

Points clés

• CVE-2026-112816 (CVSS 10,0) permet de contourner l'authentification TLS mutuelle de LXD et MicroCloud en ajoutant le certificat public d'un client de confiance à sa propre chaîne de certificats, sans en détenir la clé privée.
• L'exploitation exige un accès réseau à l'API HTTPS, non exposée par défaut sur un serveur LXD autonome, mais structurellement présente entre les membres d'un cluster MicroCloud.
• Les correctifs sont disponibles : LXD 6.10.1, 5.21.9, 5.0.11 et 4.0.15, MicroCloud 3.4.1 et 2.1.5, Incus 7.6.0.
• Aucune exploitation active n'est signalée à ce jour par Canonical, la CISA ou les chercheurs ayant documenté la faille.
• À défaut d'indicateur de compromission public, la détection repose sur la surveillance des connexions inhabituelles à l'API et sur un inventaire des certificats clients autorisés après correctif.

Le catalogue CVE de ForenShield permet de suivre l'évolution de cette vulnérabilité, et notre guide sur le score CVSS aide à comprendre pourquoi une note de 10,0 ne signifie pas toujours un risque identique selon le contexte de déploiement.

Sources

• Canonical, avis de sécurité critique LXD et MicroCloud
• Ubuntu, fiche CVE-2026-112816
• Incus, avis de sécurité GHSA-xg75-xf37-cph9
• The Hacker News : CVSS 10.0 LXD, MicroCloud Flaw Lets Attackers Impersonate Trusted Clients