La faille d’APT dans Debian et Ubuntu met à l’épreuve le patching de Linux dans le cloud

J. Actualclo

Debian et Ubuntu ont publié le 4 novembre 2026 de nouvelles versions d’APT (Advanced Package Tool, le gestionnaire de paquets des deux distributions) pour corriger la CVE-2026-109518, une faille qui permet à un attaquant placé entre le serveur et le dépôt de glisser un paquet manipulé et de l’installer avec les privilèges root. L’erreur exige des conditions réseau précises, mais elle touche l’outil qui sert à mettre à jour tout le reste, ce qui en fait un bon test de la manière dont les entreprises gèrent le patching de leurs flottes Linux, de leurs images de machines virtuelles et de leurs conteneurs.

Les points clés de la faille d’APT dans Debian et Ubuntu en 30 secondes

Debian et Ubuntu ont publié le 04/11/2026 des versions d’APT qui corrigent la CVE-2026-109518, découverte par Max Justicz.
Un attaquant placé sur le trafic HTTP, ou un miroir ou proxy malveillant, peut remplacer un paquet déjà vérifié et exécuter du code en tant que root.
Il faut des redirections et des nouvelles tentatives de téléchargement ; elles sont activées par défaut depuis Debian 12 et Ubuntu 22.04.
Canonical lui attribue un score de 7,7 en CVSS 4.0 et aucune exploitation ni preuve de concept publique n’est connue.

Le cas a été détaillé par OpenSecurity, qui reprend l’avis APT-2026-11-01 de Julian Andres Klode, mainteneur d’APT et auteur du correctif pour toutes les branches stables. Le découvreur est Max Justicz, le même chercheur qui avait trouvé en 2019 la CVE-2019-3462, une autre faille d’APT liée à la manipulation des téléchargements. La CVE (Common Vulnerabilities and Exposures, le catalogue public des vulnérabilités) a été enregistrée par Canonical en tant que CNA (CVE Numbering Authority, entité habilitée à attribuer des identifiants).

Le problème se situe dans le composant HTTP d’APT. Lorsqu’une redirection fait pointer deux téléchargements distincts vers la même URI, APT peut les fusionner. Si le téléchargement est interrompu puis repris, la réutilisation de liens physiques permet de remplacer le paquet après que la signature a déjà été vérifiée. Il s’agit d’une condition de concurrence de type TOCTOU (time-of-check to time-of-use, l’intervalle entre la vérification et l’utilisation). Comme les scripts d’un paquet .deb s’exécutent avec les droits d’administrateur, le résultat peut être une exécution de code en tant que root.

Ce dont un attaquant a besoin et quelles versions corrigent la faille

La faille ne s’exploite pas depuis n’importe quel point d’internet. Il faut une attaque MITM (man-in-the-middle, de l’homme du milieu) : l’attaquant doit contrôler le chemin HTTP entre la machine et le dépôt, que ce soit sur le même réseau, dans un proxy compromis ou à la tête d’un miroir. En outre, le serveur doit être en train d’installer ou de mettre à jour des paquets à ce moment-là, l’attaquant doit pouvoir forcer des redirections et des erreurs transitoires, et APT doit réessayer les téléchargements.

Ce dernier point explique pourquoi la faille touche surtout les systèmes récents. L’option Acquire::Retries vaut 3 par défaut depuis APT 2.3.2, la version livrée avec Debian 12 et Ubuntu 22.04. Les versions antérieures ne sont pas exposées avec leur configuration d’origine, même si de nombreux administrateurs ont activé les nouvelles tentatives à la main pour composer avec des miroirs instables, et c’est pourquoi les correctifs ont aussi été portés sur d’anciennes branches.

Canonical évalue la faille à 7,7 sur 10 en CVSS 4.0 (Common Vulnerability Scoring System), ce qui correspond à une gravité élevée, et lui attribue une priorité haute dans Ubuntu. Klode la qualifie de critique dans son avis. À la date du 5 novembre, aucune exploitation active ni preuve de concept publique n’est connue. Selon Canonical, la faille touche toute interface reposant sur APT (apt, apt-get, aptitude ou les outils graphiques d’Ubuntu), mais pas l’installation de paquets snap. La même mise à jour corrige plusieurs accès mémoire hors limites qui, selon Klode, permettent tout au plus un déni de service dans des services comme PackageKit.

Système	APT corrigé	Avis
Debian 12 bookworm	2.6.2	DLA-4880-1
Debian 13 trixie	3.0.4	DSA-6607-1
Debian sid	3.3.6	Pas d’avis propre
Debian forky (testing)	En attente (3.3.5 vulnérable)	Arrivera depuis sid
Ubuntu 26.10	3.3.3ubuntu0.1	USN-8996-1
Ubuntu 26.04 LTS	3.2.1ubuntu0.1	USN-8996-1
Ubuntu 24.04 LTS	2.8.4ubuntu0.1	USN-8996-1
Ubuntu 22.04 LTS	2.4.15ubuntu0.1	USN-8996-1
Ubuntu 20.04 LTS	2.0.12+esm1 (Ubuntu Pro)	USN-8996-1
Ubuntu 18.04 LTS	1.6.19+esm1 (Ubuntu Pro)	USN-8996-1
Ubuntu 16.04 LTS	1.2.36+esm1 (Ubuntu Pro)	USN-8996-1
Ubuntu 14.04 LTS	1.0.1ubuntu2.24+esm4 (Ubuntu Pro)	USN-8996-1

Debian 11 et Debian 10 ne reçoivent le correctif que via Extended LTS (ELTS), le support étendu payant, et le projet APT a en outre publié les branches 2.2.5 et 1.8.2.4. Les distributions dérivées qui compilent leur propre APT doivent publier leurs propres mises à jour.

Pour vérifier la version installée et ne mettre à jour que le paquet concerné, Canonical recommande de désactiver les nouvelles tentatives pendant la mise à jour elle-même, afin que le correctif ne puisse pas être attaqué pendant son téléchargement :

apt list --installed '?source-package(^apt$)'
sudo apt update && sudo apt install -o Acquire::Retries=0 --only-upgrade '?source-package(^apt$)'

Flottes, modèles et images : là où APT reste à la traîne

Dans une entreprise de plusieurs dizaines ou centaines de serveurs, le correctif ne s’applique pas une seule fois mais partout où vit APT. Les serveurs en production sont la partie facile. Selon Canonical, unattended-upgrades est activé par défaut depuis Ubuntu 16.04 et applique les mises à jour de sécurité toutes les 24 heures ; les machines dont cette configuration est intacte devraient donc déjà avoir le correctif. Le wiki de Debian explique que la configuration par défaut installe les mises à jour de sécurité et non de nouvelles fonctionnalités, même si le paquet peut ne pas être installé ou être désactivé. Il convient de le vérifier avec sudo unattended-upgrade -d et de consulter les journaux de /var/log/unattended-upgrades/, car un service à l’arrêt ne prévient pas.

Les fenêtres de maintenance restent nécessaires pour ce qui ne peut pas être appliqué à chaud, mais ce cas ne requiert pas de redémarrage. Livepatch n’entre pas non plus en jeu : Canonical précise que son service de correctif à chaud ne couvre que le noyau et que les bibliothèques et programmes de l’espace utilisateur relèvent d’unattended-upgrades ou d’un outil de gestion comme Landscape. Livepatch réduit les redémarrages dus aux failles du noyau, il ne remplace pas la mise à jour des paquets.

Le point faible se trouve souvent dans ce qui n’est pas allumé. Les modèles de machines virtuelles, les images dorées des fournisseurs cloud et les images de base de conteneurs embarquent la version d’APT qu’elles avaient le jour de leur création. Un conteneur construit aujourd’hui sur une base Debian 12 ou Ubuntu 22.04 non mise à jour traîne un APT vulnérable, et il installe justement des paquets pendant la construction, souvent via le proxy ou le miroir du pipeline d’intégration continue. Il faut donc reconstruire ces images avec la base à jour, vérifier la version d’APT qu’elles contiennent et retirer du registre celles qui ne doivent plus être utilisées.

Anciennes versions et Ubuntu Pro

Les branches d’Ubuntu hors du support standard dépendent d’Ubuntu Pro. Selon Canonical, Ubuntu 20.04 et 18.04 reçoivent les correctifs via ESM (Expanded Security Maintenance, maintenance de sécurité étendue), tandis que 16.04 et 14.04 nécessitent en plus le module Legacy. Ubuntu Pro est gratuit jusqu’à cinq machines pour un usage personnel. En pratique, une entreprise qui maintient encore des serveurs sous 18.04 sans abonnement ne recevra pas ce correctif, et il en va de même pour Debian 10 ou 11 sans ELTS.

Miroirs, proxys et chaîne d’approvisionnement des paquets

De nombreuses organisations ne téléchargent pas les paquets directement depuis les dépôts officiels. Elles utilisent des miroirs internes, des caches comme apt-cacher-ng ou des proxys d’entreprise pour économiser de la bande passante et contrôler ce qui arrive en production. Ce maillon intermédiaire correspond exactement à la position dont cette attaque a besoin. La signature des dépôts protège l’intégrité de bout en bout, mais ici le paquet est remplacé après sa vérification ; se fier uniquement à la signature ne suffit donc pas tant qu’APT n’est pas mis à jour.

Canonical indique que le chiffrement du trafic en HTTPS empêche un attaquant intermédiaire de manipuler les téléchargements et propose de basculer les sources d’APT en HTTPS lorsque ce risque ne peut être écarté. Elle prévient que certains miroirs communautaires ne prennent pas en charge HTTPS. OpenSecurity apporte la nuance que HTTPS ne protège pas si c’est le miroir ou le proxy de confiance qui est compromis. Une fois l’APT corrigé installé, selon Canonical, un miroir compromis ne représente plus un risque pour cette faille.

À titre de mesure temporaire sur les systèmes qui ne peuvent pas encore être mis à jour, OpenSecurity propose de fixer Acquire::Retries à 0 et de retirer ce réglage après l’application du correctif, tout en vérifiant quelles sources utilisent encore HTTP :

echo 'Acquire::Retries "0";' | sudo tee /etc/apt/apt.conf.d/99-cve-2026-109518
grep -rn "http://" /etc/apt/sources.list /etc/apt/sources.list.d/

Inventaire : savoir ce qui est corrigé et ce qui ne l’est pas

Répondre à un avis comme celui-ci suppose de savoir quelle version d’APT se trouve sur chaque serveur, modèle et image. Pour Debian, le Debian Security Tracker indique l’état de chaque CVE par version de la distribution. Pour Ubuntu, Canonical publie les USN (Ubuntu Security Notices) et des données OVAL (Open Vulnerability and Assessment Language) dans un format lisible par machine, que des outils compatibles SCAP comme OpenSCAP peuvent utiliser pour auditer un système ou une image cloud officielle à partir de son manifeste :

wget https://security-metadata.canonical.com/oval/com.ubuntu.$(lsb_release -cs).usn.oval.xml.bz2
bunzip2 com.ubuntu.$(lsb_release -cs).usn.oval.xml.bz2
oscap oval eval --report report.html com.ubuntu.$(lsb_release -cs).usn.oval.xml

La pression sur les délais de correction n’est pas nouvelle : l’IA accélère la recherche de vulnérabilités et oblige à repenser le patching, et en octobre, les distributions et panneaux d’administration ayant corrigé PHP2Shell ont fait l’objet d’un examen. Dans le cas d’APT, le risque pratique est plus limité que dans d’autres failles récentes, mais il concerne le mécanisme qui distribue toutes les autres corrections.

Questions fréquentes

Quelles versions de Debian et Ubuntu sont exposées par défaut à la CVE-2026-109518 ?

Celles qui embarquent APT 2.3.2 ou une version ultérieure, avec Acquire::Retries à 3 : Debian 12, Debian 13 et Ubuntu 22.04 et suivantes. Les anciennes versions ne sont exposées que si quelqu’un a activé les nouvelles tentatives à la main.

Suffit-il d’utiliser des dépôts HTTPS pour éviter la faille ?

Selon Canonical, TLS empêche un attaquant intermédiaire de manipuler le trafic. OpenSecurity prévient que cela ne protège pas si le miroir ou le proxy lui-même est compromis ; la correction complète consiste donc à installer la version corrigée d’APT.

Faut-il reconstruire les images de conteneurs et de machines virtuelles ?

Oui, si elles partent d’une base avec un APT vulnérable et doivent installer des paquets. Mettre à jour les serveurs en production ne modifie pas les modèles ni les images stockées dans le registre.

Comment mettre à jour APT sur Ubuntu 20.04 ou les versions antérieures ?

Ces branches reçoivent le correctif sous forme de paquets +esm via Ubuntu Pro, gratuit pour un usage personnel jusqu’à cinq machines. Sur Debian 11 et 10, le correctif arrive par le programme payant Extended LTS.

Sources :