CVE-2026-112816 : Bypass d’authentification critique dans LXD et MicroCloud permettant la prise de contrôle du cluster

Canonical a publié des mises à jour de sécurité concernant CVE-2026-112816, une vulnérabilité critique de contournement d’authentification affectant LXD et MicroCloud. Le défaut a un score CVSS maximal de 10,0 et peut permettre à un attaquant distant non authentifié de se faire passer pour un client TLS de confiance sans posséder la clé privée de ce client.

Une exploitation réussie peut fournir un accès à l’API LXD ou MicroCloud avec les privilèges attribués à l’identité usurpée. Lorsque l’identité de confiance dispose de permissions suffisantes, un attaquant peut obtenir un accès complet au cluster, aux machines virtuelles gérées et potentiellement un accès de niveau root à l’hôte sous-jacent.

La vulnérabilité provient d’une validation incorrecte des chaînes de certificats clients utilisées pour l’authentification mutuelle TLS. Au lieu d’authentifier uniquement le certificat feuille pour lequel le client prouve la possession de la clé privée correspondante, les implémentations vulnérables comparent chaque certificat fourni dans la chaîne contrôlée par le client avec des certificats de confiance.

Un attaquant qui peut atteindre l’API HTTPS et obtenir le certificat public d’un client déjà de confiance peut donc ajouter ce certificat derrière un certificat feuille contrôlé par l’attaquant et être accepté comme l’identité de confiance.

Canonical a divulgué le problème fin octobre 2026 après que la vulnérabilité a été référée par le projet Incus. Des versions corrigées de LXD et MicroCloud sont maintenant disponibles, et il est fortement recommandé aux administrateurs de mettre à jour immédiatement.

La faille est particulièrement significative dans les environnements d’infrastructure parce que LXD gère les conteneurs système et les machines virtuelles, tandis que MicroCloud coordonne l’infrastructure en cluster. La compromission d’une identité administrative peut donc s’étendre au-delà d’un seul service et fournir le contrôle sur les charges de travail ou l’hôte lui-même.

Pour la détection de CVE-2026-112816, les équipes de sécurité doivent prioriser l’identification des API HTTPS de LXD et MicroCloud accessibles via Internet ou réseau, examiner les certificats clients de confiance, et corréler l’authentification réussie par certificat avec des systèmes sources inattendus ou des opérations administratives inhabituelles.

La Plateforme d’Intelligence Détective Native AI de SOC Prime permet aux équipes de sécurité de renforcer la couverture pour l’exploitation et le comportement post-compromise à travers la télémétrie réseau, Linux, cloud, conteneur et identité.

Contacter les ventes

Cliquez sur Explorer les Détections pour accéder aux contenus de détection pertinents et à la logique de chasse. Pour détecter CVE-2026-112816, les défenseurs devraient combiner l’inventaire des versions vulnérables avec la surveillance d’accès API, la télémétrie d’authentification par certificat, et des activités administratives suspectes affectant les conteneurs, les machines virtuelles ou la configuration de cluster.

Analyse de CVE-2026-112816

CVE-2026-112816 est une vulnérabilité de validation incorrecte de certificat dans l’écouteur HTTPS utilisé par Canonical LXD et MicroCloud.

Les deux produits peuvent utiliser le TLS mutuel pour authentifier les clients distants. En comportement mTLS normal, le client connectant présente un certificat et prouve la possession de la clé privée associée au certificat utilisé comme feuille de la chaîne TLS.

Le problème survient parce que les implémentations vulnérables de LXD et MicroCloud inspectent plus que ce certificat feuille authentifié.

Selon Canonical, la logique d’authentification de l’API distante a comparé tous les certificats présentés par un client aux entrées du magasin de certificats de confiance. Cependant, TLS prouve la possession de la clé privée uniquement pour le certificat feuille. Les certificats supplémentaires dans la chaîne présentée sont fournis par le client et ne prouvent pas indépendamment la possession de leurs clés privées correspondantes.

Cela crée un écart d’authentification.

Un attaquant peut générer un certificat et une clé privée qu’il contrôle, utiliser ce certificat comme feuille, et ajouter le certificat public d’un client de confiance ailleurs dans la chaîne présentée. Le serveur vulnérable peut trouver le certificat de confiance et associer la connexion à cette identité de confiance même si l’attaquant ne possède pas sa clé privée.

Les détails pour CVE-2026-112816 montrent donc que l’exploitation dépend principalement de deux prérequis :

• L’attaquant peut atteindre l’API HTTPS de LXD ou MicroCloud.
• L’attaquant possède le certificat public d’une identité déjà de confiance par la cible.

La clé privée du client de confiance n’est pas requise.

Cette distinction explique la sévérité critique de la vulnérabilité. L’authentification par certificat est censée démontrer la possession d’une clé privée secrète, mais la logique affectée permet effectivement la possession du seul certificat public pour satisfaire une partie de la décision de confiance.

Une installation LXD autonome n’expose pas son API HTTPS distante par défaut. The Hacker News note que LXD écoute normalement uniquement sur son socket Unix local sauf si un administrateur active l’accès réseau, par exemple via la configuration core.https_address.

Cela signifie que toutes les installations LXD vulnérables ne sont pas exploitables à distance depuis un autre hôte.

L’exposition devient significativement plus élevée lorsque les administrateurs activent l’API sur un réseau de gestion ou l’exposent à Internet.

MicroCloud présente un autre scénario d’attaque pertinent. Canonical indique qu’un attaquant qui peut intercepter le certificat TLS public d’une machine rejoignant un cluster MicroCloud peut ensuite s’authentifier comme ce membre rejoint.

CVE-2026-112816 affecte les versions vulnérables de Canonical LXD y compris 4.0.14, 5.0.10, 5.21.8 et 6.9 avant leurs versions fixes correspondantes.

Canonical liste ces versions patchées de LXD :

• LXD 6.10.1 pour le canal 6/stable
• LXD 5.21.9 pour 5.21/stable
• LXD 5.0.11 pour 5.0/stable
• LXD 4.0.15 pour 4.0/stable

Pour MicroCloud, les versions corrigées sont :

• MicroCloud 3.4.1 pour 3/stable
• MicroCloud 2.1.5 pour 2/stable

Le dossier CVE d’Ubuntu décrit l’exploitation réussie comme permettant à un attaquant non authentifié de s’authentifier en tant que client de confiance et d’accéder pleinement au cluster et aux machines virtuelles gérées à travers une chaîne de certificats fabriquée.

Le score CVSS maximal de 10,0 reflète l’accessibilité réseau, la complexité d’attaque faible, aucune autorisation requise, et aucune interaction utilisateur nécessaire, combinés à un impact potentiellement élevé sur la confidentialité, l’intégrité et la disponibilité.

L’impact dépend finalement des privilèges de l’identité usurpée.

Une identité restreinte peut offrir des capacités API limitées. Un client ou une identité de cluster hautement privilégié peut offrir un accès substantiellement plus grand.

Canonical avertit explicitement que l’usurpation d’un utilisateur de confiance privilégié peut entraîner un accès root à la machine hôte.

Cela peut potentiellement permettre à un attaquant de :

• Gérer ou modifier des conteneurs et des machines virtuelles.
• Accéder à des charges de travail gérées via l’environnement LXD compromis.
• Modifier la configuration de l’infrastructure.
• Créer de nouvelles charges de travail ou en modifier des existantes.
• Interférer avec la disponibilité.
• Accéder aux données disponibles pour l’identité usurpée.
• Potentiellement atteindre l’hôte avec des privilèges de niveau root lorsque des permissions suffisantes sont disponibles.

La faille a été initialement identifiée dans le projet Incus associé et puis référée à Canonical, qui a confirmé que le même problème d’authentification par chaîne de certificats affectait LXD.

Incus décrit le problème sous-jacent de manière similaire : le serveur a demandé des certificats clients sans vérifier la chaîne soumise entière, tandis que les vérifications de confiance itéraient sur chaque certificat pair fourni plutôt que de restreindre l’authentification au certificat feuille réel. Incus a résolu le problème dans la version 7.6.0.

La vulnérabilité semble avoir existé pendant une période prolongée. Incus indique que la logique d’authentification équivalente était présente depuis sa sortie initiale. L’avis public de Canonical ne fournit pas de date exacte pour quand le comportement vulnérable de LXD a été introduit pour la première fois.

Au 2 novembre 2026, une preuve de concept indépendante et la reproduction en laboratoire de CVE-2026-112816 ont été publiées publiquement. Cela représente un changement par rapport au rapport de The Hacker News publié le 1er novembre affirmant qu’aucun exploit fonctionnel n’avait encore été publié. La reproduction publique est apparue après la divulgation et n’est pas la recherche de vulnérabilité d’origine.

Canonical et les rapports référencés n’ont pas indiqué que la vulnérabilité a été exploitée dans des attaques réelles.

The Hacker News rapporte que le problème n’était pas connu pour être exploité d’après l’évaluation du CISA des États-Unis datée du 30 octobre et n’était pas inclus dans le catalogue des vulnérabilités exploitées connues du CISA à ce moment-là.

Il n’y a donc pas d’IOC spécifiques à une campagne pour CVE-2026-112816 tels que des adresses IP malveillantes confirmées, des domaines, des hachages de logiciels malveillants ou des infrastructures d’attaquants connues associées à l’exploitation.

Les défenseurs devraient plutôt se concentrer sur l’exposition à la vulnérabilité et le comportement.

Les opportunités de chasse potentielles incluent :

• Connexions distantes aux API HTTPS de LXD ou MicroCloud depuis des systèmes inattendus.
• Authentification API réussie provenant de réseaux qui ne sont normalement pas utilisés par des administrateurs de confiance.
• Une identité de certificat de confiance apparaissant depuis plusieurs systèmes sources non liés.
• Activité d’API administrative qui ne correspond pas au propriétaire attendu d’un certificat.
• Création, suppression ou modification inattendue de conteneurs et de machines virtuelles.
• Changements des entrées de certificats de confiance.
• Nouveaux ou modifiés membres de cluster.
• Modifications inattendues du stockage, du réseau, des profils, des projets, ou de la configuration des instances.
• Opérations privilégiées survenues peu après une authentification inhabituelle par certificat.
• Connexions API aux interfaces de gestion qui n’étaient pas destinées à être accessibles à distance.

Les organisations devraient également inventorier les certificats de confiance associés aux anciens administrateurs, aux hôtes retraités, aux systèmes d’automatisation, et aux membres du cluster.

Parce que l’exploitation nécessite le certificat public plutôt que la clé privée, les défenseurs ne devraient pas considérer la confidentialité des clés privées seule comme une protection suffisante contre cette vulnérabilité spécifique.

La surveillance devrait également tenir compte des réseaux de gestion partagés.

Une API qui n’est pas exposée directement sur Internet public peut encore être exploitable par un attaquant qui a déjà pris pied sur un autre système capable d’atteindre l’interface de gestion.

Cela rend le mouvement latéral particulièrement pertinent. Un poste de travail compromis, un serveur, un exécuteur CI/CD, un hôte de gestion ou une charge de travail cloud avec accès réseau à l’API LXD pourrait fournir la position nécessaire pour exploiter un système autrement exposé en interne.

Atténuation de CVE-2026-112816

Canonical recommande de mettre à jour les déploiements de LXD et MicroCloud affectés vers les dernières versions corrigées immédiatement.

Pour les déploiements basés sur Snap, les administrateurs peuvent mettre à jour en utilisant :

sudo snap refresh lxd

et :

sudo snap refresh microcloud

Après la mise à jour, vérifiez la version réellement installée plutôt que de supposer que la mise à jour a été appliquée avec succès.

Canonical a noté lors de la divulgation que certaines versions ponctuelles de LXD passaient des canaux candidats à stables. Les administrateurs devraient donc confirmer explicitement que leur système tourne sur l’une des versions corrigées.

La principale atténuation de CVE-2026-112816 est de passer à :

Produit	Version corrigée
LXD 6.x	6.10.1
LXD 5.21	5.21.9
LXD 5.0	5.0.11
LXD 4.0	4.0.15
MicroCloud 3.x	3.4.1
MicroCloud 2.x	2.1.5

Canonical n’a pas publié de solution basée sur la configuration qui élimine complètement le défaut d’authentification sous-jacent.

Si une mise à jour immédiate est impossible, limitez l’accès réseau à l’API HTTPS aussi agressivement que le permettent les exigences opérationnelles.

Seuls les hôtes de gestion autorisés et l’infrastructure de confiance devraient pouvoir établir des connexions à l’écouteur.

Pour les installations LXD qui ne nécessitent pas de gestion à distance, les administrateurs devraient évaluer si l’API réseau doit rester activée du tout.

Pour les environnements nécessitant un accès à distance :

• Restreignez l’API en utilisant des pare-feux hôte ou réseau.
• Autorisez les connexions uniquement depuis des réseaux de gestion dédiés.
• Évitez d’exposer l’API directement sur Internet public.
• Utilisez un accès administratif basé sur VPN ou bastion là où c’est approprié.
• Segmentez l’infrastructure de gestion des conteneurs et de la virtualisation des réseaux utilisateur.
• Surveillez toutes les demandes d’API administratives réussies.
• Examinez les certificats de confiance et supprimez les entrées qui ne sont plus nécessaires.

Ces contrôles réduisent l’exposition mais ne corrigent pas la logique de validation des certificats vulnérables.

Les organisations exécutant MicroCloud devraient prioriser la mise à jour de tous les membres du cluster concernés et examiner l’activité récente de jointure pour des systèmes ou des identités de certificats inattendus.

Les administrateurs devraient également examiner leurs magasins de certificats de confiance.

Supprimez les certificats appartenant à des hôtes mis hors service, des anciens administrateurs, des systèmes d’automatisation inutilisés, ou des identités qui n’ont plus besoin d’accès.

Lorsque des activités suspectes sont découvertes, enquêtez sur l’hôte et le cluster affectés avant de faire tourner les informations d’identification ou de modifier les preuves.

Les sources de télémétrie pertinentes peuvent inclure :

• Journaux de service LXD et MicroCloud
• Journaux système Linux
• Enregistrements de flux réseau et de pare-feu
• Télémétrie de proxy inverse, si applicable
• Données EDR de l’hôte
• Journaux réseau cloud
• Configuration du cluster et historique des membres
• Dossiers de changement administratif

Recherchez une création, modification, suppression, activité de snapshot inattendue d’instance, opérations de stockage, changements de réseau, et mises à jour de configuration.

Si l’exploitation est suspectée et qu’une identité de certificat privilégiée a été usurpée, les défenseurs devraient traiter le compromis potentiel au niveau de l’hôte sérieusement parce que Canonical confirme que l’accès root peut être possible en fonction des permissions de l’identité de la victime.

Les intervenants en cas d’incident devraient préserver les preuves pertinentes et inspecter le système pour la persistance, les comptes ou certificats non autorisés, les services modifiés, les nouvelles charges de travail, les processus suspects, et la communication réseau sortante anormale.

Les organisations utilisant Incus plutôt que Canonical LXD devraient mettre à jour séparément vers Incus 7.6.0 ou la version corrigée supportée pertinente parce que le projet connexe était affecté par le même problème de confiance de chaîne de certificats.

Ubuntu note également que ses versions de LXD emballées dans les archives pour les versions Ubuntu actuellement listées ne sont soit pas livrées par le chemin du paquet affecté ou ne sont pas affectées, tandis que les directives de sécurité de Canonical se concentrent sur les versions Snap. Les administrateurs devraient néanmoins vérifier la distribution LXD réelle et la version exécutée dans leur environnement plutôt que de supposer une exposition basée uniquement sur la version Ubuntu.

Avertissement : Le contenu de détection peut ne pas être disponible pour chaque CVE. Vérifiez la plateforme SOC Prime pour la couverture actuelle. Si les détections pertinentes ne sont pas encore disponibles, vérifiez à nouveau car de nouvelles données d’intelligence sur les menaces et du contenu de détection sont continuellement ajoutés.