Osegi
Sécurité·2 min de lecture

Canonical corrige une faille de gravité maximale dans LXD

Canonical a corrigé CVE-2026-112816, une faille notée 10,0 dans LXD et MicroCloud qui permet d'usurper un client de confiance sans sa clé privée.

Server racks in a data center with a digital padlock overlay symbolizing a critical container management vulnerability.
Image: Хабр
SUMO Dialo ediviewer giftdetect

Le 28 octobre, Canonical a annoncé la correction de la vulnérabilité CVE-2026-112816 dans LXD, son gestionnaire de conteneurs et de machines virtuelles, ainsi que dans MicroCloud, sa plateforme de cloud privé. La base de connaissances CodeScoring la classe comme critique, avec la note maximale de 10,0 selon CVSS 4.0. Elle permet d'usurper l'identité d'un client de confiance sans détenir sa clé privée.

Le mécanisme de l'attaque

L'erreur réside dans la vérification de la chaîne de certificats du client. Lors de la connexion TLS, le client ne prouve la possession de la clé privée que pour le premier certificat de la chaîne. Or le serveur comparait tous les certificats reçus au magasin des clients de confiance. Un attaquant pouvait donc présenter son propre certificat en premier, y ajouter le certificat public d'un client de confiance et hériter de ses droits.

L'attaque exige un accès à l'API HTTPS d'administration et le certificat public du client visé. MicroCloud connaît un scénario supplémentaire : l'attaquant intercepte le certificat public d'un nœud pendant son adhésion à un cluster, puis se fait passer pour ce nœud.

C'est le projet Incus, fork ouvert de LXD, qui a signalé le problème à Canonical. Le certificat du serveur lui-même s'obtient lors d'une connexion TLS ; l'ajouter à sa chaîne donne accès à la passerelle de la base de données, tandis que celui d'un autre nœud ouvre l'accès interne au cluster. Incus a corrigé la faille dans la version 7.6.0, les versions antérieures étant vulnérables. Selon CodeScoring, le défaut existait dans Incus depuis la première version, et le même contournement permettait de prolonger ou de supprimer des entrées du magasin de certificats.

Ce que doivent faire les administrateurs

Par défaut, LXD fonctionne via un socket Unix local et n'accepte aucune connexion réseau. L'accès réseau s'active avec le paramètre core.https_address ; il faut donc d'abord vérifier si l'interface d'administration est joignable depuis un réseau non fiable.

Les versions corrigées des paquets snap datent du 29 octobre : 6.10.1, 5.21.9, 5.0.11 et 4.0.15 pour LXD, 3.4.1 et 2.1.5 pour MicroCloud. Canonical recommande d'exécuter sudo snap refresh lxd et sudo snap refresh microcloud. Le déploiement étant progressif, il convient de comparer la version obtenue à la liste de son canal.

En attendant, l'accès à l'API doit être limité aux hôtes de confiance. Les développeurs d'Incus soulignent qu'aucun réglage ne supprime la faille sans mise à jour. LXD, MicroCloud et Incus doivent aussi figurer à l'inventaire des logiciels d'infrastructure des hôtes de conteneurs et de machines virtuelles.

Des apps à découvrir

SUMO : le puzzle de nombres

Touche les bonnes cases, additionne, atteins l'objectif. Facile à apprendre, difficile à maîtriser. Gratuit, pour tous les âges.

Mots-clés:canonicallxdmicrocloudincuscve-2026-112816vulnerability

Plus d'actus de ce jour

Tout voir →

Plus dans: Sécurité

Tout voir →