Incus 7.6, 7.0.2 LTS et 6.0.7 LTS : 18 nouvelles failles dont 8 critiques, un projet restreint pouvait devenir root sur l'hôte

Sources : annonces d'Incus 7.6, 7.0.2 LTS et 6.0.7 LTS sur linuxcontainers.org (29 et 30 octobre 2026) ; avis de sécurité publiés sur le dépôt GitHub lxc/incus ; DSA-6604-1 de Debian (2 novembre 2026).

Le projet Linux Containers a publié coup sur coup trois versions d'Incus, le gestionnaire de conteneurs système et de machines virtuelles né du fork de LXD : Incus 7.0.2 LTS et Incus 6.0.7 LTS le 29 octobre 2026, puis Incus 7.6 le 30 octobre. La version mensuelle corrige 18 failles de sécurité rendues publiques le 29 octobre au soir : 8 critiques, 5 élevées et 5 moyennes. La plus grave, notée 10 sur 10, permettait de s'authentifier sur l'API à la place de n'importe quel client de confiance sans posséder sa clé privée. Plusieurs autres laissaient un utilisateur cantonné à un projet restreint exécuter du code en root sur l'hôte.

Pour un administrateur, la bonne question n'est pas seulement « quelle version ? » mais « quel canal d'installation ? ». Les notes de 7.0.2 et de 6.0.7 ne mentionnent pas ces 18 avis, qui visent toutes les versions antérieures à 7.6.0 : ce sont le dépôt Zabbly et Debian qui ont rétroporté les correctifs dans leurs paquets LTS. Cet article fait le point sur ce qui a été corrigé, sur qui est réellement exposé, sur la façon de vérifier sa version et de mettre à jour selon sa branche, et sur les nouvelles exigences de la 7.0.2 : Go 1.26, Open vSwitch 3.3.0 et OVN 24.03.0. Pour l'installation de départ, voir notre guide installer Incus sur un serveur dédié.

Trois versions en deux jours : ce que corrige chacune

Incus suit deux rythmes de publication : une version mensuelle qui apporte des fonctionnalités et n'est supportée que jusqu'à la suivante, et des branches LTS (long term support) qui ne reçoivent que des correctifs. Les trois annonces d'octobre listent chacune leurs avis de sécurité, avec un niveau de gravité pour chaque faille.

La liste de la 6.0.7 ne contient que des failles déjà corrigées dans des versions mensuelles antérieures, comme le précise son annonce. Celle de la 7.0.2 en partage la plupart, et plusieurs de ces CVE avaient déjà donné lieu à des avis Debian en juin et en juillet. On y retrouve des traversées de chemin à l'import de sauvegardes et de volumes, des liens symboliques piégés dans des images (backup.yaml, metadata.yaml), une injection d'arguments via block.create_options et deux failles du pilote de stockage Btrfs qui touchent aussi LXD. La 6.0.7 est la septième version corrective de la branche 6.0, passée en maintenance de sécurité seule depuis la sortie d'Incus 7.0 LTS.

Les 18 avis de la 7.6 sont d'une autre nature. Publiés le 29 octobre sur GitHub, ils déclarent vulnérables toutes les versions du module Go incus/v7 antérieures à 7.6.0, ce qui couvre la branche 7.0 LTS, et le suivi de sécurité Debian montre que la branche 6.0 est également touchée. Le correctif tient en vingt commits regroupés dans la PR « Security fixes for Incus 7.6 » (n° 4293), fusionnée le 30 octobre. Aucune version 7.0.3 ou 6.0.8 n'est sortie depuis : sur les LTS, ce sont les paquets qui portent les correctifs.

Les 8 failles critiques d'Incus 7.6

Les scores CVSS 3.1 ci-dessous sont ceux des avis GitHub. La colonne de droite indique ce dont un attaquant a besoin, ce qui permet de savoir si votre configuration est concernée.

Comment un projet restreint finissait root sur l'hôte

Les projets Incus servent à cloisonner plusieurs utilisateurs sur un même serveur : chaque client reçoit un certificat limité à son projet, et la clé restricted=true bloque les fonctions sensibles. Mais un projet ne sépare un type de ressource que si la clé features.* correspondante vaut true. Sinon, il hérite de celles du projet default. Or la documentation indique que features.networks vaut false à la création d'un projet : par défaut, les réseaux sont partagés avec default.

Incus vérifiait l'autorisation sur le projet nommé dans la requête, mais créait la ressource dans le projet effectif, c'est-à-dire default, qui n'a aucune restriction. Un client limité à son projet pouvait donc y créer un pont réseau dont l'option raw.dnsmasq contenait une directive dhcp-script. Comme dnsmasq est lancé en root, il exécute le script choisi par l'attaquant dès son démarrage, sans qu'aucun conteneur ni bail DHCP soit nécessaire. Deuxième chemin : un volume personnalisé dont l'option block.create_options est transmise à mkfs, lui aussi exécuté en root sur les pools en mode bloc. Avec -d /etc, le formatage recopie le /etc de l'hôte, /etc/shadow compris, dans un système de fichiers que le locataire peut monter.

Le contournement d'authentification par chaîne de certificats

L'écouteur HTTPS d'Incus demandait un certificat client mais ne le vérifiait pas. La poignée de main TLS prouvait seulement que le client possédait la clé du premier certificat de sa chaîne, alors que le contrôle d'accès comparait chaque certificat de la chaîne au magasin de confiance. Il suffisait donc d'ajouter à sa chaîne la partie publique d'un certificat de confiance. Cette partie publique n'a rien de secret : un serveur Incus l'envoie à chaque connexion TLS, ce qui permettait de se présenter comme un membre de cluster. L'avis précise que le défaut existe depuis la première version d'Incus et qu'il n'existe aucun contournement par la configuration : seule la restriction réseau de l'accès à l'API protège en attendant la mise à jour. Le suivi de sécurité Debian rattache ce défaut à la CVE-2026-112816 de LXD, que nous avons couverte en octobre.

Images OCI : une image piégée suffit

Incus sait lancer des conteneurs applicatifs depuis un registre OCI, Docker Hub par exemple, ajouté avec incus remote add docker https://docker.io --protocol=oci. Pour générer la configuration LXC du conteneur, il lit le config.json de l'image : variables d'environnement, point d'entrée, répertoire de travail. Ces valeurs étaient recopiées sans contrôle dans un format ligne par ligne. Un retour à la ligne dans une variable ajoutait donc des directives LXC arbitraires, y compris des hooks que liblxc exécute en root sur l'hôte, et les points de montage tmpfs déclarés par l'image permettaient de monter des chemins de l'hôte dans le conteneur. Depuis Incus 7.5.0, ce fichier était lu pour toute image qui en contenait un, pas seulement pour les images OCI : une simple archive importée suffisait. La restriction restricted.images.servers ne protège pas, puisqu'elle ne couvre pas l'import d'une archive locale.

Les 10 autres failles : 5 élevées, 5 moyennes

Gravité élevée :

• GHSA-3rgf-297m-775x : un utilisateur local de l'hôte peut détourner les sockets NBD utilisés pour la migration et l'export de disque des machines virtuelles ;
• GHSA-8r3h-vc36-6xpx : des clients restreints ou en lecture seule peuvent lire des ressources du projet default ;
• GHSA-9c46-v3hw-v6m8 : un conteneur reconstruit (rebuild) sans avoir jamais démarré boote sans espace de noms utilisateur, donc en conteneur privilégié ;
• GHSA-h2j8-4crh-vhfc : les secrets des websockets de migration apparaissent dans les événements du projet, ce qui permet de détourner une migration ;
• GHSA-v736-5xp3-jghf : un nom de cgroup forgé permet d'usurper l'identité d'une autre instance auprès de l'API invité.

Gravité moyenne :

• GHSA-8mgx-h4v8-xqv2 : l'écouteur S3 met en mémoire le corps des requêtes signées avant de les authentifier ;
• GHSA-9f75-5fjw-5jvv : les journaux des ACL OVN sont diffusés avec un projet vide et fuient d'un projet à l'autre ;
• GHSA-f7xp-22ph-v444 : l'export d'image par l'API invité ignore le projet de l'instance et expose les images d'autres projets ;
• GHSA-pf5w-m8m6-5265 : les réponses récursives et « tous projets » divulguent les clés S3 des buckets et la configuration des profils d'autres projets, correctif incomplet d'un avis précédent ;
• GHSA-x6pw-mh5w-pq73 : une entrée de snapshot vide dans une sauvegarde d'instance provoque un déni de service.

Qui est exposé : les situations à risque

Aucune des huit failles critiques ne s'exploite depuis l'intérieur d'une instance : il faut soit joindre l'API, soit disposer d'un accès à un projet, soit faire consommer au serveur une image, une sauvegarde ou une migration piégée. Seules deux failles de moindre gravité passent par l'API invité (dev_incus) accessible depuis les instances. Le niveau de risque dépend donc de la façon dont vous utilisez Incus.

Le cas le moins exposé est celui d'un serveur administré par une seule personne, où le daemon n'écoute que sur son socket Unix local : c'est le comportement par défaut documenté, tant que vous n'avez pas défini core.https_address. Les membres du groupe incus-admin sont de toute façon équivalents à root sur la machine. Il reste alors un risque à ne pas négliger : lancer une image OCI publique dont vous ne connaissez pas l'auteur revenait, avant le correctif, à lui confier une exécution en root sur l'hôte.

Vérifier sa version d'Incus et son exposition

Commencez par la version et par l'origine du paquet installé :

incus version
apt policy incus
zgrep " upgrade incus:" /var/log/dpkg.log*

incus version affiche la version du client et celle du serveur : c'est la seconde qui compte. apt policy incus indique la version installée, la version candidate et le dépôt d'origine (pkgs.zabbly.com, deb.debian.org, security.debian.org ou archive.ubuntu.com). Sur les branches LTS de Zabbly, le numéro reste 7.0.2 ou 6.0.7 après le rétroportage : la troisième commande montre la date de la dernière mise à jour du paquet, qui doit être postérieure au 30 octobre 2026.

Regardez ensuite si l'API est joignable depuis le réseau et qui y a accès :

incus config get core.https_address
incus config get cluster.https_address
ss -tlnp | grep incusd
incus config trust list
incus project list

Une réponse vide aux deux premières commandes signifie que l'API n'écoute que sur le socket Unix local. Une valeur comme :8443 veut dire qu'elle écoute sur toutes les interfaces, IP publique comprise. incus config trust list liste les certificats de confiance : repérez ceux que vous ne reconnaissez pas, ainsi que les certificats restreints confiés à des tiers. incus project list montre les projets et les fonctions qu'ils isolent.

Mettre à jour Incus selon la branche et le dépôt

Avec le dépôt Zabbly ou les paquets Debian, la mise à jour passe par apt, en root :

apt-get update
apt list --upgradable 2>/dev/null | grep -i incus
apt-get upgrade
incus version

La deuxième commande montre les paquets Incus en attente (incus, incus-base, incus-client, incus-extra selon ce qui est installé). Si vous êtes encore sur une version mensuelle antérieure (7.5 ou moins), passez à la 7.6 : les versions mensuelles ne reçoivent plus rien dès que la suivante sort, et la documentation renvoie vers Incus 7.0 LTS ceux qui veulent un rythme plus lent. Sur la branche 6.0, préparez la bascule vers la 7.0 LTS : la 6.0 ne reçoit plus que des correctifs de sécurité. Sur un serveur de production, exportez les instances critiques avant toute mise à jour du daemon (incus export, détaillé dans notre guide sauvegardes et haute disponibilité sur serveur dédié). Une fois la branche LTS en place, ses correctifs peuvent passer par les mises à jour de sécurité automatiques.

Go 1.26, Open vSwitch 3.3.0 et OVN 24.03.0 : les nouvelles exigences

L'annonce de la 7.0.2 relève les prérequis de la branche LTS : Go 1.26 pour compiler Incus, Open vSwitch 3.3.0 et OVN 24.03.0 pour les réseaux OVN. La 6.0.7 relève seulement la version de Go. La documentation de la branche principale donne les mêmes minimums, avec un noyau Linux 6.12, LXC 6.0, QEMU 8.2 pour les machines virtuelles, nftables 1.0.0 et dnsmasq 2.90.

Go 1.26 ne concerne que ceux qui compilent Incus eux-mêmes ou maintiennent un paquet : les paquets Zabbly et Debian livrent des binaires déjà construits. Open vSwitch et OVN ne concernent que les réseaux de type OVN, utilisés surtout en cluster. Un simple pont incusbr0 n'en dépend pas. Voici ce que livrent les distributions courantes :

Un cluster Incus qui utilise OVN sur Debian 12 ou Ubuntu 22.04 sort donc des prérequis avec la 7.0.2. C'est le moment de planifier la montée de version du système, déjà conseillée pour la branche 7 dont le noyau minimum (6.12) dépasse le noyau 6.1 de Debian 12 : voir notre guide pour migrer de Debian 12 vers Debian 13. Pour comparer avec la gestion des réseaux virtuels côté Proxmox, notre article sur Proxmox SDN détaille une approche voisine.

Si vous ne pouvez pas mettre à jour tout de suite

Les avis donnent des parades temporaires. Elles réduisent l'exposition sans remplacer le correctif.

Fermer l'API au réseau public. C'est la seule protection contre GHSA-xg75. Si vous n'utilisez ni client distant, ni interface web, ni cluster, désactivez l'écoute réseau :

incus config unset core.https_address

Sinon, limitez le port aux adresses IP de vos postes d'administration et de vos membres de cluster. Avec UFW (remplacez l'adresse par la vôtre ; la règle d'autorisation doit passer avant le refus) :

ufw allow from 198.51.100.10 to any port 8443 proto tcp
ufw deny 8443/tcp

Avec nftables, adaptez la même logique à votre table (voir nftables comme pare-feu). Plus simple encore : n'exposer l'API que sur un réseau privé WireGuard, comme expliqué dans notre guide Tailscale sur VPS Linux.

Resserrer les projets restreints. Fixez restricted.networks.access à la liste des réseaux existants pour empêcher la création de réseaux, seule parade documentée pour ce cas. Activez les clés features.* sur les projets confiés à des tiers (la plupart exigent un projet vide). Ne confiez pas la création d'images, d'instances ou de sauvegardes à des locataires non fiables tant que le correctif n'est pas en place, et ne délivrez pas de certificat restreint sur le projet default :

incus project set client1 restricted.networks.access=incusbr0
incus project show client1

Contrôler les sources. Ne lancez que des images de sources de confiance, n'importez que vos propres sauvegardes et ne migrez des instances que depuis des serveurs que vous maîtrisez.

Chercher des traces. L'avis GHSA-jcw9 conseille d'auditer le projet default à la recherche d'objets créés par des locataires, en particulier des ponts réseau avec raw.dnsmasq et des volumes avec block.create_options :

incus network list --project default
incus network get incusbr0 raw.dnsmasq
incus storage volume list default --project default
incus config trust list

Dans la troisième commande, le premier default est le nom du pool de stockage créé à l'initialisation : adaptez-le à vos pools. Répétez incus network get pour chaque réseau inconnu et retirez les certificats que vous ne reconnaissez pas avec incus config trust remove <empreinte>. Au moindre doute sur une compromission, traitez l'hôte comme celui d'un serveur dédié piraté : notre guide pour sécuriser un serveur dédié rappelle les réglages de base à refaire.

Ce qu'apporte aussi Incus 7.6

Au-delà de la sécurité, la 7.6 vise surtout les grands environnements :

• migration à chaud entre membres d'un cluster des VM équipées de cartes réseau SR-IOV ;
• migrations à chaud plus rapides grâce au transfert parallèle multifd de QEMU, avec une option de plafond de bande passante ;
• volumes personnalisés sur pool local capables de suivre leur VM vers un autre membre du cluster ;
• confiance accordée à une autorité de certification : les certificats clients qu'elle émet sont acceptés sans mettre à jour le magasin de confiance à chaque renouvellement ;
• filtrage MAC et IP sur les cartes OVN, changement du réseau parent d'un réseau OVN, communautés BGP sur les préfixes annoncés ;
• délai configurable avant l'évacuation d'un membre de cluster hors ligne ;
• compteurs d'entrées-sorties disque dans l'état des instances (VM seulement pour l'instant) et prise en charge préliminaire de l'architecture loongarch64.

Ce que ça change pour un serveur dédié partagé

Beaucoup d'administrateurs utilisent Incus pour découper un serveur dédié entre plusieurs usages : le serveur de jeu d'une communauté, le site web, la base de données, parfois l'espace d'un ami ou d'un client. Ces avis rappellent une règle simple : donner à quelqu'un un accès à l'API d'Incus, même limité à un projet, c'est lui faire confiance sur l'hôte entier tant que le daemon n'est pas à jour. Une VM ne change rien à ce risque, puisque les failles sont dans le daemon et dans son API, pas dans le noyau partagé par les conteneurs.

Pour un tiers à qui vous ne faites pas pleinement confiance, donnez plutôt un accès SSH à sa propre instance, sans certificat sur l'API. S'il doit gérer ses propres conteneurs, un VPS Linux séparé reste l'isolation la plus nette. Et quel que soit le cas, l'API d'Incus n'a rien à faire sur une IP publique sans filtrage.

En résumé

Incus 7.6 corrige 18 failles publiées le 29 octobre, dont 8 critiques : une authentification contournable par chaîne de certificats (CVSS 10), des projets restreints qui pouvaient créer des ressources dans default et obtenir root sur l'hôte, des images OCI capables d'injecter de la configuration LXC, des traversées de chemin à l'import de sauvegardes et à la migration. Sur la branche mensuelle, passez à la 7.6. Sur les LTS 7.0 et 6.0, mettez à jour les paquets Zabbly reconstruits le 30 octobre ou le paquet Debian 6.0.4-2+deb13u12, puis vérifiez la date de mise à jour. En attendant, fermez le port de l'API au réseau public et retirez les droits de création aux locataires dont vous n'êtes pas sûr. Les clusters OVN sur Debian 12 ou Ubuntu 22.04 doivent en plus prévoir la montée vers Open vSwitch 3.3.0 et OVN 24.03.0.