Canonical a publié des correctifs pour une faille de vérification des certificats qui permet à des attaquants d'usurper l'identité de clients LXD et MicroCloud de confiance, sans leurs clés privées, selon The Hacker News. L'avis de sécurité d'Ubuntu publié le 30 octobre identifie la vulnérabilité LXD sous le nom CVE-2026-112816. Elle peut donner à un attaquant non authentifié un accès complet à un cluster et aux machines virtuelles qu'il gère.
L'exploitation nécessite un accès réseau à l'API HTTPS, c'est-à-dire l'interface chiffrée qui sert à gérer le service, ainsi que le certificat public d'une identité que le serveur approuve. L'attaquant obtient les accès de cette identité. Selon les déclarations de Canonical rapportées par The Hacker News, l'usurpation d'un compte privilégié pourrait aussi donner un accès root à la machine hôte.
Les installations LXD autonomes n'exposent pas cette interface réseau par défaut. Elles écoutent sur un socket local, sauf si un administrateur active l'accès réseau via core.https_address. MicroCloud, qui regroupe en cluster des machines exécutant LXD, présente une exposition particulière : Canonical indique qu'un attaquant qui capture le certificat public d'un membre pendant son adhésion au cluster peut ensuite usurper l'identité de ce membre.
La vulnérabilité affiche un score maximal de 10,0 selon le Common Vulnerability Scoring System, tandis qu'Ubuntu lui attribue une priorité de correction distincte, Medium. The Hacker News rapporte qu'une évaluation de la CISA datée du 30 octobre, consignée dans l'enregistrement CVE, qualifiait l'exploitation de non connue. La faille ne figurait pas dans le catalogue Known Exploited Vulnerabilities de la CISA, et aucun exploit fonctionnel n'avait été publié.
Comment un certificat public permet de se connecter
LXD et MicroCloud prennent en charge le TLS mutuel, une configuration de connexion dans laquelle les clients présentent des certificats pour établir leur identité. Les serveurs conservent les identités acceptées dans un magasin de confiance. Un certificat public n'est pas secret ; sa clé privée associée est censée prouver que le client possède l'identité.
La faille rompt ce principe. Lors de la négociation de la connexion, TLS ne prouve la possession de la clé privée que pour le premier certificat présenté, appelé certificat feuille (leaf certificate). Pourtant, le mécanisme d'authentification vulnérable comparait chaque certificat de la chaîne du client au magasin de confiance, y compris les certificats supplémentaires que le client pouvait joindre librement.
Un attaquant pourrait donc présenter d'abord son propre certificat, puis y joindre le certificat public d'un client de confiance. Le serveur accepterait alors l'identité de confiance, alors même que l'attaquant ne possède pas la clé privée correspondante.
Le projet Incus, un fork communautaire de LXD, a signalé le problème, et Canonical a confirmé que LXD était lui aussi touché, selon The Hacker News. Incus a publié son propre avis de sécurité le 29 octobre, la veille de l'avis d'Ubuntu. Cet avis indique que le comportement existe depuis la première version d'Incus et touche les versions antérieures à 7.6.0.
Incus décrit d'autres voies d'accès
L'avis Incus détaille des conséquences dans ce produit, au-delà de l'usurpation d'un client ordinaire. Toute personne pouvant atteindre son écouteur HTTPS peut usurper un client de confiance, une identité de métriques ou un certificat serveur dont elle possède le certificat public. Usurper un membre de cluster contourne entièrement l'autorisation.
Obtenir un certificat public adapté peut ne nécessiter aucun accès préalable dans Incus, car les serveurs renvoient leurs certificats à chaque négociation TLS. Joindre le certificat du serveur ciblé donne accès à la passerelle de base de données ; joindre celui d'un autre membre du cluster donne un accès interne au cluster. Des clients de confiance peuvent aussi récupérer des certificats clients via l'API certificates, et des certificats peuvent être obtenus auprès des serveurs que ces clients ont contactés.
Incus indique que la faille permet également de renouveler ou de supprimer n'importe quelle entrée du magasin de confiance via des chemins en libre-service, et qu'elle affecte l'authentification de la connexion entre les hôtes et les machines virtuelles, assurée par l'agent.
Une autre conséquence concerne le scriptlet d'autorisation, un script qui sert à prendre les décisions d'accès. Incus transmettait à ce script la chaîne de certificats non vérifiée, ce qui permettait à des certificats choisis par l'attaquant d'influencer ces décisions. Cela touche aussi les clients qui s'authentifient par jetons ou par OpenID Connect, une méthode de connexion fondée sur l'identité, car ils peuvent tout de même présenter des certificats arbitraires lors de la négociation TLS.
Ces impacts détaillés proviennent de l'avis Incus. Celui-ci suit le problème sous l'identifiant GHSA-xg75-xf37-cph9 et ne mentionne aucun identifiant CVE connu.
Versions corrigées et mesures pour les administrateurs
L'avis d'Ubuntu indique que LXD 4.0.14, 5.0.10, 5.21.8 et 6.9 sont concernés avant leurs versions corrigées respectives. The Hacker News rapporte les versions snap corrigées suivantes, classées par produit et canal :
- LXD
6/stable: 6.10.1. - LXD
5.21/stable: 5.21.9. - LXD
5.0/stable: 5.0.11. - LXD
4.0/stable: 4.0.15. - MicroCloud
3/stable: 3.4.1. - MicroCloud
2/stable: 2.1.5.
Le statut des paquets d'archive Ubuntu est distinct de ces installations snap. Ses paquets LXD pour Ubuntu 20.04, 18.04 et 16.04 sont marqués comme non affectés ; LXD n'est pas présent dans les versions 22.04, 24.04, 26.04 et 26.10.
Les administrateurs qui utilisent les snaps doivent mettre à jour les produits installés avec sudo snap refresh lxd et sudo snap refresh microcloud. Canonical a indiqué que les versions correctives de LXD étaient encore en cours de passage du canal candidate vers le canal stable au moment de la publication de son avis. Il est donc recommandé de vérifier la version installée après la mise à jour.
Selon The Hacker News, l'avis de Canonical ne propose aucune solution de contournement temporaire pour LXD. Restreindre l'accès réseau à l'API HTTPS réduit l'exposition pendant l'application des mises à jour. Incus recommande explicitement de limiter son écouteur HTTPS aux hôtes de confiance et indique qu'il n'existe aucune solution de contournement reposant sur la configuration. Les administrateurs d'Incus doivent passer à la version 7.6.0, qui corrige cette faille ainsi que dix-sept autres problèmes de sécurité.
