Contournement de l’authentification mTLS de LXD et Incus (CVE-2026-112816)

TL;DR

• Une faille dans l’API HTTPS de Canonical LXD, MicroCloud et Incus permet à un attaquant réseau de s’authentifier comme n’importe quel client de confiance sans la clé privée de ce client. Le projet Incus l’a signalée et Canonical a confirmé que LXD et MicroCloud étaient touchés ; Canonical a publié son avis le 28 octobre 2026.
• Un démon touché et non corrigé est exposé si l’attaquant peut joindre son API HTTPS et obtenir le certificat public d’une identité de confiance. Incus présente les certificats de serveur pendant TLS ; l’avis MicroCloud décrit l’interception du certificat d’un membre qui rejoint la grappe. Aucune authentification, aucun privilège ni interaction utilisateur ne sont requis.
• L’enregistrement CVE de Canonical le classe Critical, CVSS v4.0 10,0. Aucune exploitation n’est connue et il est absent du catalogue KEV de la CISA au 1er novembre 2026. Les avis cités ne renvoient à aucune preuve de concept publique.
• Mettez à jour LXD et MicroCloud avec sudo snap refresh lxd et sudo snap refresh microcloud, et passez Incus en 7.6.0. Restreindre l’accès réseau à l’écouteur HTTPS est la mesure d’attente recommandée, et ce n’est pas un correctif.

Suis-je concerné ?

Vous êtes exposé quand toutes ces conditions tiennent :

• Un démon dans les plages touchées ci-dessous est en cours d’exécution : LXD, MicroCloud ou Incus.
• Son API HTTPS écoute sur une adresse réseau joignable par un attaquant. Un démon LXD autonome sert par défaut un socket Unix local et ne lie l’écouteur réseau que lorsqu’une adresse est configurée, d’après son code d’endpoints ; les grappes et les clients distants exigent l’API réseau.
• L’attaquant peut obtenir le certificat public d’une identité de confiance. Les certificats de serveur sont renvoyés à chaque négociation TLS, donc le chemin d’attaque le plus direct ne demande aucun accès préalable.

L’avis Incus indique que le schéma défaillant est présent depuis la version initiale : les installations Incus antérieures à 7.6.0 sont donc touchées.

Canonical distribue LXD et MicroCloud sous forme de snaps ; les archives Ubuntu ne contiennent aucun paquet LXD touché, et le propre suivi d’Ubuntu classe le problème Medium. Les versions corrigées ci-dessus sont les versions snap selon l’avis de Canonical.

Vérifiez ce que vous exécutez et si l’API réseau est active :

snap list lxd
lxc version
lxc config get core.https_address
lxc config get cluster.https_address
snap list microcloud

Vérifiez les adresses des écouteurs API et de grappe : une adresse API vide n’exclut pas un écouteur de grappe. Incus utilise les mêmes clés de configuration :

incus version
incus config get core.https_address
incus config get cluster.https_address

Comment corriger ?

Mettez à jour chaque démon LXD et MicroCloud vers la version corrigée de son canal, et Incus vers 7.6.0 :

1. Rafraîchissez les snaps : sudo snap refresh lxd et sudo snap refresh microcloud.
2. Confirmez que le démon exécute bien une version corrigée : snap list lxd puis lxc version. Canonical note que toutes les versions ponctuelles de LXD étaient en déploiement progressif du canal candidate vers stable à la publication de son avis, donc revérifiez après le rafraîchissement plutôt que de supposer le correctif arrivé.
3. Mettez à jour Incus via son canal de paquets vers 7.6.0, qui corrige aussi 17 autres problèmes de sécurité selon son annonce de version.

Il n’existe aucune parade par configuration. La mesure d’attente recommandée est de restreindre l’accès réseau à l’écouteur HTTPS aux hôtes de confiance, comme le recommande l’avis Incus jusqu’à la mise à jour. Sa limite est claire : la faille reste dans le démon, et tout chemin non fiable vers l’écouteur la laisse ouverte.

Quelle est la cause première ?

Les vérifications de confiance comparaient chaque certificat envoyé par le client au magasin de confiance. Une négociation TLS prouve seulement que le client possède la clé privée du premier certificat de la chaîne, et le reste de la chaîne est contrôlé par le client. L’écouteur HTTPS de LXD et Incus demande un certificat client avec tls.RequestClientCert de Go, qui réclame la chaîne sans la vérifier.

Le démon Incus portait la forme la plus claire du défaut, dans Authenticate dans cmd/incusd/daemon.go avant la version 7.6.0 :

    // Allow internal cluster traffic by checking against the trusted certficates.
    if r.TLS != nil {
        for _, i := range r.TLS.PeerCertificates {
            trusted, fingerprint := localUtil.CheckTrustState(*i, trustedCerts[certificate.TypeServer], d.endpoints.NetworkCert(), false)
            if trusted {
                return true, fingerprint, "cluster", nil, nil
            }
        }
    }

La même boucle sur r.TLS.PeerCertificates s’exécutait pour les certificats clients ordinaires comme pour les certificats de métriques, où i vaut successivement chaque certificat présenté. r.TLS.PeerCertificates est l’ensemble des certificats remis par le client, dans l’ordre choisi par le client. CheckTrustState compare un certificat aux entrées du magasin de confiance, donc la boucle transforme une chaîne assemblée par le client en liste d’identités candidates.

Ajouter le certificat public d’une identité de confiance comme élément supplémentaire de chaîne authentifie donc l’attaquant comme cette identité. Le certificat feuille prouve qui est l’attaquant ; le certificat ajouté décide de qui le serveur croit qu’il est.

Comment la faille est-elle exploitée ?

L’attaque demande une connexion TLS et un certificat public :

1. L’attaquant capture le certificat public d’une identité de confiance. Un certificat de serveur sort de n’importe quelle négociation TLS avec le démon, donc aucun accès préalable n’est nécessaire. Un certificat client peut être lu via l’API certificates par tout client de confiance, ou collecté auprès de tout serveur auquel ce client s’est connecté.
2. L’attaquant se connecte à l’API HTTPS avec son propre certificat et sa clé privée, et ajoute le certificat public capturé à la chaîne présentée.
3. La négociation réussit, car l’écouteur ne fait que réclamer la chaîne et ne vérifie rien au-delà de la clé de la feuille.
4. La boucle de confiance parcourt la chaîne présentée, fait correspondre le certificat ajouté à une entrée du magasin de confiance, et authentifie l’attaquant comme cette identité.

L’usurpation fonctionne aussi contre les chemins de certificat en libre-service. L’avis indique qu’un client pouvait renouveler ou supprimer n’importe quelle entrée du magasin de confiance. Il indique aussi que la chaîne non vérifiée atteignait le scriptlet d’autorisation, permettant à un client d’y introduire des certificats choisis par l’attaquant. Les avis cités ne renvoient à aucune preuve de concept publique. Rien de tout cela n’exige plus que la joignabilité réseau.

Comment se déroule l’attaque ?

Une seule connexion à l’écouteur HTTPS, avec le certificat public de l’identité de confiance placé dans la chaîne, suffit pour devenir cette identité.

Que peut faire un attaquant ?

L’attaquant hérite de tout ce que l’identité usurpée peut faire, sur les produits touchés :

• Un accès complet à la grappe et à ses machines virtuelles gérées, selon l’enregistrement CVE. Canonical indique que lorsque l’utilisateur usurpé est privilégié, l’attaquant peut obtenir un accès root à la machine hôte.
• L’accès à la passerelle de base de données en présentant le certificat du serveur lui-même, et l’accès interne à la grappe en présentant le certificat d’un autre membre, selon l’avis Incus. Usurper un membre de grappe contourne entièrement l’autorisation.
• Le renouvellement et la suppression de toute entrée du magasin de confiance via les chemins en libre-service. La même faille alimente le scriptlet d’autorisation, donc un client peut influencer les décisions d’autorisation du scriptlet. Cela vaut aussi pour les clients par token ou OpenID Connect, qui peuvent encore présenter un certificat arbitraire pendant la négociation.
• L’usurpation de la connexion d’agent entre l’hôte et les machines virtuelles, qui porte la même faille.

Dans MicroCloud, Canonical avertit qu’un attaquant capable d’intercepter le certificat TLS public d’un membre pendant qu’il rejoint la grappe peut ensuite s’authentifier comme ce membre. Les conditions restent les mêmes : joignabilité réseau de l’API plus un certificat public, sans privilège ni interaction utilisateur.

Pourquoi le correctif fonctionne-t-il ?

Le correctif public de référence est le commit Incus 8381e54c3631c627d7ecdec03945bca14d0bd542, « Only trust the key-proven client certificate », rédigé le 13 octobre 2026 par Stéphane Graber :

+   // The TLS listener only proves possession of the first peer certificate's key, so the rest of
+   // the presented chain is attacker-controlled and must never be matched against the trust store.
+   var peerCert *x509.Certificate
+   if r.TLS != nil && len(r.TLS.PeerCertificates) > 0 {
+       peerCert = r.TLS.PeerCertificates[0]
+   }

Les vérifications de confiance s’exécutent ensuite uniquement contre peerCert, remplaçant chaque boucle sur r.TLS.PeerCertificates :

-   if r.TLS != nil {
-       for _, i := range r.TLS.PeerCertificates {
-           trusted, fingerprint := localUtil.CheckTrustState(*i, trustedCerts[certificate.TypeServer], d.endpoints.NetworkCert(), false)
-           if trusted {
-               return true, fingerprint, "cluster", nil, nil
-           }
-       }
-   }
+   if peerCert != nil {
+       trusted, fingerprint := localUtil.CheckTrustState(*peerCert, trustedCerts[certificate.TypeServer], d.endpoints.NetworkCert(), false)
+       if trusted {
+           return true, fingerprint, "cluster", nil, nil
+       }
+   }

Un certificat ajouté ne peut plus rien faire correspondre, car seule la feuille réellement vérifiée par la négociation est consultée. Le commit applique la même règle à chaque chemin de confiance listé par l’avis. Cela couvre l’authentification de l’API, l’enrôlement de certificat et le renouvellement et la suppression en libre-service, la connexion d’agent hôte-machine virtuelle des deux côtés, le scriptlet d’autorisation et le trafic de grappe.

Pour LXD et MicroCloud, l’avis de Canonical décrit la même correction, et les versions corrigées listées dans « Suis-je concerné ? » la portent.

Comment vérifier si j’ai été compromis ?

Les avis des fournisseurs ne publient aucun indicateur de compromission. Un magasin de confiance inchangé n’exclut pas une usurpation : un attaquant peut utiliser une identité existante sans créer d’entrée.

Commencez par rechercher des entrées inattendues dans le magasin de confiance et les membres de la grappe :

lxc config trust list

lxc cluster list

Examinez chaque entrée du magasin de confiance pour un nom, un type ou un jeu de projets inattendus. Portez une attention particulière aux entrées qui ont été renouvelées, car le chemin de renouvellement en libre-service fait partie de la faille. Si une identité privilégiée a pu être usurpée sur un hôte, traitez cet hôte comme compromis. Évaluez tous les identifiants accessibles depuis cet hôte, y compris les clés privées, et renouvelez ceux qui ont pu être exposés lors d’une compromission. Reconstruisez les hôtes selon votre procédure de réponse à incident.

Chronologie

Le commit de correctif Incus a été rédigé 17 jours avant la publication du CVE. Sa date de rédaction ne prouve pas quand le commit est devenu public.

• 2023-07-22 : le dépôt Incus est créé comme une fourche de LXD. L’avis Incus indique que le schéma défaillant est présent depuis la version initiale.
• 2026-10-13 : Stéphane Graber rédige le correctif Incus, commit 8381e54c3631c627d7ecdec03945bca14d0bd542.
• 2026-10-19 : Canonical réserve CVE-2026-112816.
• 2026-10-21 : Canonical annonce LXD 6.10.1, première version corrigée de la branche 6.x.
• 2026-10-28 : Canonical publie son avis de sécurité avec les versions snap corrigées de LXD et MicroCloud.
• 2026-10-29 : Incus publie GHSA-xg75-xf37-cph9. Les versions snap corrigées de LXD et MicroCloud portent la date du 29 octobre 2026.
• 2026-10-30 : l’enregistrement CVE est publié et Incus 7.6.0 sort. L’ADP de la CISA conclut à aucune exploitation connue, daté du 30 octobre 2026.

FAQ

Pourquoi la négociation TLS ne prouve-t-elle pas toute la chaîne ?

L’écouteur demande un certificat client avec tls.RequestClientCert de Go, qui réclame la chaîne mais ne la vérifie pas. La négociation prouve seulement que le client possède la clé privée du premier certificat de la chaîne ; chaque certificat suivant est une donnée que le client a choisi d’attacher.

Une installation LXD autonome par défaut est-elle exposée ?

Non. Un démon autonome sert son socket Unix local et ne lie l’écouteur HTTPS que lorsqu’un administrateur configure une adresse réseau. L’installation par défaut n’est donc pas joignable par le réseau. Les grappes et tout client lxc distant exigent cette API réseau.

Dois-je renouveler mes certificats après le correctif ?

La divulgation du seul certificat public ne nécessite pas de renouvellement : ce certificat n’est pas secret. Le correctif ferme le contournement. Si un attaquant a accédé à l’hôte, évaluez séparément l’exposition des clés privées et autres identifiants, renouvelez les éléments compromis et recherchez des modifications non autorisées du magasin de confiance.

Les failles LXD et Incus sont-elles le même défaut ?

Elles partagent un mécanisme dans deux bases de code d’une lignée commune. Stéphane Graber, créateur de LXD et d’Incus, l’a signalée ; Incus l’a corrigée dans 7.6.0 et Canonical a corrigé LXD et MicroCloud dans les versions listées plus haut. L’avis de Canonical couvre LXD et MicroCloud, et l’avis Incus est publié sans identifiant CVE.

La faille est-elle exploitée en conditions réelles ?

Aucune exploitation n’est connue. L’ADP de la CISA a évalué l’exploitation comme nulle le 30 octobre 2026, et la faille est absente du catalogue KEV de la CISA au 1er novembre 2026. Les avis cités ne renvoient à aucune preuve de concept publique.

Trouvez vos hôtes LXD et Incus exposés avec Ostorlab

La découverte de surface d’attaque d’Ostorlab inventorie vos hôtes exposés sur Internet, pour repérer quels démons LXD, Incus et MicroCloud exposent l’API HTTPS et corriger ces derniers en premier.

Références

• Enregistrement CVE-2026-112816, CNA Canonical, CVSS v4.0 10.0 : https://www.cve.org/CVERecord?id=CVE-2026-112816 (vérifié le 1er novembre 2026)
• Avis de sécurité Canonical avec les versions snap corrigées : https://discourse.ubuntu.com/t/security-advisory-critical-vulnerability-found-in-canonical-lxd-and-microcloud/90557 (publié le 28 octobre 2026 ; vérifié le 1er novembre 2026)
• Avis Incus GHSA-xg75-xf37-cph9, CVSS v3.1 10.0 : https://github.com/lxc/incus/security/advisories/GHSA-xg75-xf37-cph9 (publié le 29 octobre 2026 ; vérifié le 1er novembre 2026)
• Commit de correctif Incus « Only trust the key-proven client certificate » : https://github.com/lxc/incus/commit/8381e54c3631c627d7ecdec03945bca14d0bd542 (rédigé le 13 octobre 2026 ; vérifié le 1er novembre 2026)
• Annonce de version LXD 6.10.1 : https://discourse.ubuntu.com/t/lxd-6-10-1-lts-has-been-released/90024 (publiée le 21 octobre 2026 ; vérifiée le 1er novembre 2026)
• Annonce de version Incus 7.6, 18 correctifs de sécurité : https://discuss.linuxcontainers.org/t/incus-7-6-has-been-released/27462 (publiée le 30 octobre 2026 ; vérifiée le 1er novembre 2026)
• Page de suivi Ubuntu pour CVE-2026-112816, état des paquets d’archive et priorité Medium : https://ubuntu.com/security/CVE-2026-112816 (vérifiée le 1er novembre 2026)
• Code des endpoints LXD, socket Unix local par défaut et écouteur HTTPS configuré : https://github.com/canonical/lxd/blob/lxd-6.10.1/lxd/endpoints/endpoints.go (vérifié le 1er novembre 2026)
• Catalogue KEV de la CISA, flux vérifié pour CVE-2026-112816 : https://www.cisa.gov/known-exploited-vulnerabilities-catalog (vérifié le 1er novembre 2026)
• The Hacker News, « CVSS 10.0 LXD, MicroCloud Flaw Lets Attackers Impersonate Trusted Clients Without a Private Key » : https://thehackernews.com/2026/11/critical-lxd-and-microcloud-flaw-cvss.html (publié le 1er novembre 2026 ; vérifié le 1er novembre 2026)