Une faille d’authentification au cœur de la confiance
Canonical fait face à une vulnérabilité critique dans LXD et MicroCloud, identifiée comme CVE-2026-112816 et notée 10.0 en CVSS 4.0 . Ce score maximal n’est pas anecdotique: la faille touche le mécanisme même qui permet à l’API HTTPS de reconnaître les clients de confiance. Dans un schéma TLS mutuel, un client n’est pas censé être accepté simplement parce qu’un certificat connu apparaît quelque part; il doit prouver qu’il possède la clé privée correspondant à son certificat.
Le registre CVE indique que le défaut concerne la validation des certificats dans l’écouteur HTTPS de Canonical LXD, avec les versions affectées 4.0.14 avant 4.0.15, 5.0.10 avant 5.0.11, 5.21.8 avant 5.21.9 et 6.9.0 avant 6.10.1 . La base GitHub Advisory décrit le même problème comme permettant à un attaquant non authentifié de s’authentifier comme n’importe quel client de confiance et d’obtenir l’accès au cluster ainsi qu’aux machines virtuelles gérées au moyen d’une chaîne de certificats forgée . Pour des environnements de conteneurs, de machines virtuelles ou de cloud privé, c’est une faiblesse du plan de contrôle, pas un simple bug périphérique.
L’exploitation n’est pas totalement ouverte. L’attaquant doit pouvoir atteindre l’API HTTPS de LXD ou MicroCloud et disposer du certificat public d’un client déjà approuvé par la cible . Mais c’est précisément là que réside le problème: un certificat public n’est pas un secret. La partie secrète est la clé privée. La logique vulnérable a traité un élément public comme s’il suffisait à établir l’identité.
Ce qui a cassé dans TLS mutuel
Le bug tient à la manière dont LXD et MicroCloud validaient les chaînes de certificats présentées pendant TLS mutuel. Dans une conception correcte, le certificat feuille du client est central, car c’est lui qui est associé à la clé privée utilisée pendant la négociation. Les autres certificats d’une chaîne peuvent accompagner la connexion, mais ils ne prouvent pas que le client détient les clés privées correspondantes.
D’après les éléments publiés sur l’avis Canonical, la logique vulnérable comparait tous les certificats pairs envoyés par le client avec les entrées du magasin de confiance, au lieu de n’utiliser que le certificat feuille pour établir l’identité . Un attaquant pouvait donc présenter sa propre connexion TLS, y ajouter plus loin dans la chaîne le certificat public d’un client de confiance, et être accepté comme ce client .
La vulnérabilité est classée CWE-295, validation incorrecte de certificat, et le registre CVE l’associe à une usurpation de signature liée à une validation insuffisante . Son vecteur CVSS 4.0 cumule des facteurs lourds: attaque réseau, faible complexité, aucune exigence de privilèges, aucune interaction utilisateur, et impacts élevés sur la confidentialité, l’intégrité et la disponibilité du système vulnérable comme des ressources gérées . C’est cette combinaison qui explique le 10.0.
Pourquoi LXD et MicroCloud aggravent l’impact
LXD n’est pas un service isolé sans pouvoir. Il sert à gérer des conteneurs et des machines virtuelles, souvent avec des droits qui dépassent largement ceux d’une application ordinaire. MicroCloud construit de son côté un petit cloud privé en cluster autour de LXD, ce qui étend encore la frontière de confiance . Une erreur d’authentification à ce niveau peut donc affecter des hôtes, des workloads et des opérations d’administration.
L’impact réel dépend de l’identité usurpée. Les comptes ou certificats de faible privilège limitent les dégâts; les identités administratives, elles, peuvent ouvrir la voie à une prise de contrôle beaucoup plus large. Les comptes rendus récents citant Canonical indiquent que, selon le client imité, l’attaquant peut obtenir un accès root à la machine hôte . Autrement dit, il ne s’agit pas seulement de franchir une page de connexion: il s’agit d’hériter de l’autorité représentée par un certificat de confiance.
MicroCloud ajoute un scénario spécifique. Les informations publiées signalent qu’un attaquant capable d’intercepter le certificat public d’un membre lors de son adhésion à un cluster pourrait ensuite s’authentifier comme ce membre . Dans un environnement distribué, les procédures de jonction peuvent paraître routinières; ici, elles deviennent un point à examiner de près.
L’exposition dépend de l’API HTTPS
La première question opérationnelle est simple: l’API HTTPS est-elle joignable? Les informations actuelles rappellent qu’un serveur LXD autonome n’expose pas cette API sur le réseau par défaut et écoute normalement seulement sur un socket Unix local, sauf si un administrateur active l’écoute réseau via core.https_address . Brandefense souligne également que les hôtes où core.https_address est défini sont ceux qui doivent être traités comme priorités immédiates .
Ce comportement par défaut réduit l’exposition opportuniste, mais ne suffit pas à rassurer. La gestion distante, les clusters, les interfaces web et les plateformes de cloud privé sont précisément les contextes où l’écoute HTTPS peut être activée. Ce sont aussi les contextes où un certificat client de confiance peut disposer de droits très puissants.
Les équipes ne devraient donc pas se contenter de l’argument “ce n’est pas exposé par défaut”. Il faut vérifier concrètement quels hôtes écoutent sur le réseau, quels certificats clients sont approuvés, quels rôles ou privilèges leur sont associés, et quelles zones réseau peuvent joindre l’API. Une instance de test locale et un cluster MicroCloud de production ne présentent pas le même risque.
Versions corrigées et vérification du déploiement
Les versions corrigées de LXD listées dans les données CVE sont 4.0.15, 5.0.11, 5.21.9 et 6.10.1 . Les publications sur l’avis Canonical indiquent aussi les versions MicroCloud corrigées 2.1.5 et 3.4.1 . La mesure immédiate consiste à rafraîchir les snaps concernés, puis à vérifier la version effectivement installée.
Cette vérification est importante. Brandefense a indiqué que, lors de ses contrôles du 31 octobre, certains canaux stables LXD servaient encore des builds vulnérables tandis que les builds corrigés étaient en cours de disponibilité, notamment pour les pistes 5.21, 5.0 et 4.0 . Les mécanismes d’auto-refresh, les gels de mise à jour, les déploiements progressifs et le choix du canal peuvent tous retarder l’arrivée réelle du correctif.
Un plan de réponse raisonnable devrait commencer par l’inventaire des nœuds LXD et MicroCloud. Il devrait ensuite identifier les écouteurs HTTPS, limiter leur accès aux réseaux d’administration, appliquer les mises à jour, confirmer les versions, revoir le magasin de confiance et supprimer les anciens certificats clients inutiles. Les journaux d’authentification méritent aussi une attention particulière, surtout pour les identités de confiance à hauts privilèges.
Exploitation connue et priorité réelle
À ce stade, les sources publiques récentes ne signalent pas d’exploitation active de CVE-2026-112816. L’enrichissement CISA SSVC visible dans le registre CVE indique une exploitation à “none”, tout en notant que le problème est automatisable et que l’impact technique est total . Brandefense rapporte également que la vulnérabilité ne figurait pas dans le catalogue Known Exploited Vulnerabilities de CISA lors de ses vérifications du 31 octobre .
Cela ne rend pas la faille secondaire. Une vulnérabilité non exploitée publiquement mais notée 10.0 sur un plan d’administration doit être traitée rapidement, surtout si l’API est accessible depuis des réseaux larges ou si des certificats clients puissants circulent dans l’organisation. La bonne priorisation n’est pas seulement “combien d’instances LXD avons-nous?”, mais “combien d’instances LXD ou MicroCloud exposent leur API HTTPS, et avec quels clients de confiance?”.
La leçon technique est nette. Un certificat public peut aider à identifier une entité, mais il ne doit jamais suffire à prouver que le demandeur est cette entité. La preuve, c’est la possession de la clé privée. Dans les versions vulnérables, LXD et MicroCloud ont accepté une sorte de tour de passe-passe façon Jedi comme justificatif d’identité: “voici bien le client de confiance que vous cherchez”. Le correctif rétablit la frontière cryptographique que TLS mutuel devait garantir.
Commentaires
Sois le premier à commenter.