CVE-2026-34179 : escalade de privilèges critique dans LXD

Les faits

Identifiée sous la référence CVE-2026-34179 et publiée le 9 avril 2026, cette vulnérabilité critique frappe Canonical LXD, le gestionnaire de conteneurs système et de machines virtuelles déployé massivement sur les infrastructures Linux, des laboratoires de test aux clusters de production. Avec un score CVSS de 9.1, elle se situe au plus haut niveau de criticité de l'échelle de notation. Le problème réside dans la gestion des certificats TLS restreints : un utilisateur légitime, censé n'accéder qu'à un périmètre limité de projets, peut contourner ces restrictions et obtenir les privilèges d'administrateur du cluster LXD. Concrètement, l'attaquant prend le contrôle de l'ensemble des conteneurs, des machines virtuelles, des volumes de stockage et des configurations réseau gérés par le cluster compromis. Les organisations exploitant LXD en environnement mutualisé ou multi-tenant sont particulièrement exposées et doivent appliquer les correctifs sans délai.

La faille se situe dans la fonction doCertificateUpdate du fichier lxd/certificates.go, responsable du traitement des mises à jour de certificats lors des requêtes PUT ou PATCH envoyées à l'endpoint API /1.0/certificates/{fingerprint}. Le champ Type de la requête entrante n'est pas validé, permettant à un utilisateur restreint de fournir une valeur arbitraire qui contourne les contrôles de sécurité destinés à maintenir son statut restreint.

Cette absence de validation constitue un défaut classique de contrôle d'accès, mais son impact est amplifié par le rôle central de LXD dans la gestion d'environnements conteneurisés en production. Une seconde vulnérabilité connexe, CVE-2026-34178, affecte également le mécanisme de restriction de projets dans les mêmes versions.

Impact et exposition

LXD est déployé dans de nombreuses infrastructures cloud privées, environnements de développement et plateformes de conteneurisation. Un attaquant disposant d'un accès limité (certificat TLS restreint) peut exploiter cette faille pour devenir administrateur complet du cluster. Cela lui permet de créer, modifier ou supprimer n'importe quel conteneur ou machine virtuelle, d'accéder aux volumes de stockage partagés et potentiellement de s'échapper vers l'hôte sous-jacent.

Le vecteur d'attaque est réseau (AV:N), la complexité est faible (AC:L) et seuls des privilèges bas sont nécessaires (PR:L), sans interaction utilisateur. Toutes les versions de LXD de 4.12 à 6.7 sont vulnérables, ce qui représente plusieurs années de déploiements en production. Les environnements multi-tenants où des utilisateurs restreints coexistent avec des administrateurs sont les plus exposés.

Recommandations immédiates

• Mettre à jour LXD vers la version 6.8 ou supérieure qui corrige la validation du champ Type
• Auditer les certificats TLS configurés dans le cluster LXD pour identifier les utilisateurs restreints
• Vérifier les journaux d'accès à l'API /1.0/certificates/ pour détecter des requêtes PUT/PATCH suspectes
• Restreindre l'accès réseau à l'API LXD aux seules adresses IP de management autorisées
• Appliquer également le correctif pour CVE-2026-34178 (contournement de restriction de projets) présent dans la même mise à jour

Décomposition du score CVSS 3.1

Le vecteur complet AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H mérite d'être détaillé pour comprendre la gravité réelle de CVE-2026-34179. Le paramètre le plus significatif est le changement de scope (S:C) : l'exploitation depuis un contexte restreint (certificat TLS cantonné à un projet ou à des permissions limitées) permet de sortir de ce périmètre pour affecter l'intégralité du cluster LXD, y compris des projets et ressources auxquels l'attaquant n'avait initialement aucun accès légitime. Les triplets C:H/I:H/A:H confirment un impact maximal simultané sur la confidentialité, l'intégrité et la disponibilité : un attaquant peut lire les données de tous les conteneurs, les modifier, ou provoquer un déni de service en supprimant des ressources critiques.

Combiné à l'absence d'interaction utilisateur (UI:N) et à des privilèges d'attaque bas (PR:L), ce profil rapproche CVE-2026-34179 des vulnérabilités historiques de rupture d'isolation en environnement multi-tenant, comme CVE-2022-0811 (CR8escape dans CRI-O) ou les échappements de conteneurs runc documentés depuis 2019. Dans le cas présent, il ne s'agit pas d'une évasion vers l'hôte au sens strict, mais d'une élévation de privilèges applicative au sein même de l'API de gestion — ce qui, pour un hébergeur ou un fournisseur d'infrastructure en marque blanche, revient au même niveau de risque opérationnel.

Mesures de mitigation en attendant le correctif

• Isolation réseau : restreindre l'accès à l'API LXD (port 8443 par défaut) aux seules adresses IP de gestion via un pare-feu, en particulier si le socket est exposé au-delà du réseau local.
• Audit des certificats : lister les certificats enregistrés avec lxc config trust list et vérifier qu'aucun certificat à privilèges restreints n'a été modifié récemment sans autorisation.
• Révocation préventive : pour les environnements ne pouvant pas patcher immédiatement, révoquer temporairement les certificats des utilisateurs non essentiels avec lxc config trust remove.
• Journalisation renforcée : activer les logs détaillés de l'API (lxd.log) pour surveiller les requêtes PUT/PATCH suspectes sur l'endpoint /1.0/certificates/.

Canonical recommande une mise à jour directe vers la 6.8 plutôt qu'un contournement manuel, la correction touchant la logique de validation du champ Type au niveau du code source et non un simple paramètre de configuration. Les distributions basées sur snap peuvent vérifier leur canal avec snap info lxd avant de forcer un snap refresh lxd.