Faille APT CVE-2026-109518 : vérifier et mettre à jour vos serveurs Debian et Ubuntu avant qu'un paquet piégé passe root

Le 4 novembre 2026, les développeurs d'APT, le gestionnaire de paquets de Debian et d'Ubuntu, ont publié un bulletin de sécurité pour la faille CVE-2026-109518. Un attaquant capable de manipuler le trafic HTTP entre votre serveur et son dépôt de paquets peut faire installer un paquet .deb de son choix, sans que la vérification des signatures ne s'y oppose. Comme dpkg installe les paquets avec les privilèges root, le résultat est une exécution de code à distance en root sur le serveur. Debian a publié les correctifs le jour même (DSA-6607-1 pour Debian 13, DLA-4880-1 pour Debian 12) et Canonical a diffusé l'avis USN-8996-1 pour toutes les versions d'Ubuntu encore suivies. Ce guide explique en quoi consiste la faille, comment savoir si votre VPS Linux ou votre serveur dédié est exposé, comment appliquer la mise à jour sans donner prise à l'attaque pendant le téléchargement, et quoi changer durablement dans la configuration de vos dépôts.

Sources : bulletin APT-2026-11-01 de Julian Andres Klode, DSA-6607-1, DLA-4880-1, fiche CVE de Canonical, billet de Canonical sur les correctifs, suivi de sécurité Debian, article d'IT-Connect.

Comment un paquet non vérifié finit installé en root

En temps normal, APT télécharge d'abord le fichier InRelease du dépôt, signé avec la clé GPG de la distribution, puis les index Packages dont les empreintes SHA-256 figurent dans ce fichier signé. Chaque paquet .deb téléchargé ensuite est comparé à l'empreinte annoncée dans l'index. Un fichier qui ne correspond pas est rejeté, ce qui permet d'utiliser des miroirs en HTTP sans confiance particulière : la signature protège le contenu, pas le transport.

La faille se situe dans le backend HTTP de la bibliothèque libapt-pkg, donc dans tous les outils qui s'en servent : apt, apt-get, aptitude, les logithèques graphiques et unattended-upgrades. D'après les annonces de Debian, APT peut fusionner deux téléchargements de paquets différents lorsqu'une redirection HTTP les envoie vers la même URI. En combinant cette redirection avec une erreur HTTP transitoire, qui pousse APT à relancer le téléchargement, un attaquant placé entre le serveur et le dépôt amène APT à écraser un lien dur (hard link) existant dans son cache de téléchargement avec un contenu qu'il contrôle. Le fichier a été vérifié avant ce remplacement et il est installé après : la vérification est contournée sans qu'aucune signature ne soit forgée. Les paquets snap ne sont pas concernés, ils utilisent un autre mécanisme de distribution.

Le vecteur CVSS résume bien la situation : aucun privilège requis (PR:N), mais une condition préalable sur l'environnement (AT:P, l'attaquant doit être sur le chemin réseau) et une action de l'utilisateur (UI:P, une installation ou une mise à jour doit être lancée). Sur un serveur de production, cette action a lieu tous les jours si les mises à jour automatiques sont actives. Le risque dépend donc surtout de la confiance que vous accordez au réseau entre le serveur et le dépôt.

Qui est concerné : le rôle de Acquire::Retries

L'option Acquire::Retries indique à APT combien de fois relancer un téléchargement qui a échoué. L'attaque exige au moins une relance. Depuis APT 2.3.2, sorti en 2021, la valeur par défaut est passée de 0 à 3, directement dans le code de la bibliothèque et non dans un fichier de configuration. Toute distribution livrée avec APT 2.3.2 ou plus récent est donc vulnérable dans sa configuration par défaut : Debian 12, Debian 13, Ubuntu 22.04 LTS et toutes les versions d'Ubuntu plus récentes. Debian 11 et Ubuntu 20.04 embarquent un APT plus ancien, où les relances sont désactivées par défaut. Ils ne sont exposés que si un script, un fichier dans /etc/apt/apt.conf.d/ ou une image système a fixé une valeur non nulle, ce qui est fréquent dans les pipelines d'intégration continue et les Dockerfiles.

Les versions corrigées, d'après les annonces de Debian et de Canonical :

Côté amont, le bulletin des développeurs d'APT liste des correctifs pour toutes les branches maintenues, de la 1.2.36 à la 3.2.1, y compris la 2.2.5 pour la branche de Debian 11. Cette distribution a toutefois quitté le support LTS le 31 août 2026 et ne reçoit plus de mise à jour de sécurité de Debian : un serveur encore en Debian 11 doit migrer vers Debian 12 ou 13 plutôt que d'attendre un paquet. Notre guide quelle distribution Linux pour un VPS compare les cycles de support. Les dérivées comme Proxmox VE, Linux Mint ou Raspberry Pi OS reprennent le paquet apt de Debian ou d'Ubuntu et reçoivent le correctif par leurs canaux habituels.

Vérifier l'état d'un serveur en trois commandes

Première chose à lire : la version d'APT installée. La commande suivante affiche la version installée et la version candidate dans vos dépôts. Comparez la ligne Installed au tableau ci-dessus :

apt policy apt

Deuxième vérification : la valeur effective de Acquire::Retries. Comme la valeur par défaut vit dans le code, apt-config dump n'affiche l'option que si un fichier de configuration l'a fixée explicitement. Un résultat vide signifie que la valeur du code s'applique : 3 avec APT 2.3.2 ou plus récent, 0 avant. Un résultat non vide sur Debian 11 ou Ubuntu 20.04 signifie qu'un script a rendu ce vieux système vulnérable :

apt-config dump | grep -i 'Acquire::Retries'
grep -ri 'retries' /etc/apt/apt.conf.d/

Troisième vérification : la part de vos dépôts encore servis en HTTP. Debian 13 et Ubuntu 24.04 déclarent leurs sources au format deb822 dans des fichiers .sources (ligne URIs:), les versions antérieures dans /etc/apt/sources.list et des fichiers .list (lignes deb). La commande suivante liste toutes les lignes concernées, quel que soit le format :

grep -rhE '^(deb |URIs:)' /etc/apt/sources.list /etc/apt/sources.list.d/ 2>/dev/null | grep 'http://'

Sur une flotte de serveurs, lancez ces commandes en une passe avec Ansible (voir notre guide Ansible pour configurer des VPS Linux) ou depuis une console Cockpit. Une ligne par serveur suffit pour savoir où intervenir en premier :

ansible all -i inventory.ini -m shell -a "apt policy apt | grep Installed"

Mettre à jour APT sans relancer les téléchargements

Il y a une subtilité propre à cette faille : pour télécharger le correctif, vous utilisez la version vulnérable d'APT. Si un attaquant est déjà sur le chemin réseau, c'est précisément pendant cette mise à jour qu'il peut agir. Canonical recommande donc de désactiver les relances pour cette exécution avec l'option -o Acquire::Retries=0 : sans relance, la condition préalable de l'attaque disparaît. La commande s'applique telle quelle sur Debian et sur Ubuntu :

sudo apt update && sudo apt upgrade -o Acquire::Retries=0

Si vous ne pouvez pas tout mettre à jour tout de suite, par exemple sur un serveur de jeu dont vous figez les paquets entre deux maintenances, limitez l'opération aux binaires issus du paquet source apt (apt, apt-utils, libapt-pkg). Le motif ?source-package est compris par APT 2.0 et suivants :

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

Avec les relances désactivées, un dépôt momentanément indisponible fait échouer la commande au lieu de réessayer en silence. Relancez-la simplement : ne remettez pas Acquire::Retries à 3 pour « que ça passe ». Aucun redémarrage n'est nécessaire, APT n'est pas un service résident. Vérifiez ensuite que la version installée correspond au tableau des versions corrigées :

apt list --installed '?source-package(^apt$)'

Sur Ubuntu 20.04 et plus ancien, le paquet corrigé n'arrive que par les dépôts ESM d'Ubuntu Pro. Si la machine n'est pas rattachée à un abonnement, la mise à jour ci-dessus ne trouvera rien à installer : c'est le moment de planifier la migration vers une version LTS encore suivie. Pour mettre à jour un serveur de jeu sans perdre sa configuration, suivez notre guide mettre à jour un serveur de jeu Linux.

Passer les dépôts en HTTPS

La faille exige de manipuler du trafic HTTP en clair. Avec des dépôts en HTTPS, un proxy ou un réseau compromis ne peut plus injecter de redirection ni d'erreur transitoire : il ne reste que le cas d'un miroir lui-même malveillant, contre lequel la vérification des signatures suffit une fois APT corrigé. Depuis APT 1.5, le transport HTTPS est intégré à APT lui-même, le paquet apt-transport-https n'est plus nécessaire. Les dépôts officiels deb.debian.org, security.debian.org, archive.ubuntu.com et security.ubuntu.com acceptent HTTPS. Sur Debian, la commande suivante réécrit les deux formats de fichiers de sources :

sudo sed -Ei 's!http://(deb|security)\.debian\.org!https://\1.debian.org!g' /etc/apt/sources.list /etc/apt/sources.list.d/*.sources 2>/dev/null
sudo apt update

Sur Ubuntu, Canonical propose une commande équivalente qui couvre les miroirs archive, security et ports, ainsi que leurs déclinaisons par pays :

sudo sed -Ei 's!http://((([a-z]+\.)?archive|security|ports)\.ubuntu\.com)!https://\1!' /etc/apt/sources.list /etc/apt/sources.list.d/*.list /etc/apt/sources.list.d/*.sources
sudo apt update

Si apt update renvoie une erreur sur une ligne, le miroir concerné ne sert pas HTTPS : certains miroirs communautaires nationaux sont dans ce cas. Remettez cette ligne en HTTP ou remplacez le miroir par le dépôt officiel. Pensez aussi aux dépôts tiers (Docker, PostgreSQL, Node.js, Proxmox) : la plupart sont déjà en HTTPS, vérifiez ceux qui ne le sont pas. Enfin, si vos serveurs passent par un cache local comme apt-cacher-ng, qui travaille en HTTP, mettez APT à jour en priorité et gardez ce cache sur un réseau que vous contrôlez. Notre guide sécuriser un serveur dédié : premiers réglages revient sur l'isolation réseau d'un serveur fraîchement installé.

Conteneurs, images et scripts d'automatisation

Les images Docker debian et ubuntu contiennent leur propre copie d'APT, utilisée à chaque RUN apt-get install d'un Dockerfile. Tant que l'image de base n'a pas été reconstruite avec la version corrigée, chaque build télécharge des paquets avec un APT vulnérable, en HTTP par défaut dans les images officielles. Deux réflexes : récupérer une image de base publiée après le 4 novembre 2026 et contrôler la version d'APT qu'elle embarque, puis désactiver les relances dans la première instruction du Dockerfile tant que l'image de base n'est pas corrigée. La vérification se fait sans démarrer de conteneur persistant :

docker pull debian:bookworm-slim
docker run --rm debian:bookworm-slim dpkg-query -W apt

Dans le Dockerfile, la première instruction met à jour APT avec les relances désactivées, et les instructions suivantes retrouvent un comportement normal :

RUN apt-get -o Acquire::Retries=0 update \
 && apt-get -o Acquire::Retries=0 install -y --only-upgrade '?source-package(^apt$)' \
 && rm -rf /var/lib/apt/lists/*

Reconstruisez ensuite vos images et redéployez les conteneurs, par exemple avec docker compose build --pull && docker compose up -d. Si vous hébergez un serveur de jeu en conteneur, nos guides FiveM sous Docker sur un VPS Linux et Docker Compose sur VPS Linux détaillent ce cycle de reconstruction.

Les scripts d'installation méritent le même examen. Un script de provisionnement, un cloud-init ou un rôle Ansible qui fixe Acquire::Retries à une valeur non nulle pour fiabiliser les téléchargements rend vulnérable un Debian 11 ou un Ubuntu 20.04 qui ne l'était pas par défaut. Cherchez cette option dans vos dépôts de code et dans /etc/apt/apt.conf.d/, et supprimez-la tant que les machines visées n'ont pas reçu le correctif. Sur Proxmox VE, qui repose sur Debian, le paquet apt corrigé arrive par le dépôt Debian déclaré dans la configuration de l'hyperviseur : appliquez-y la même mise à jour avant celle des machines virtuelles.

Ne plus dépendre d'une alerte

Cette faille n'est pas la première d'APT signalée par le même chercheur, qui avait déjà rapporté CVE-2019-3462 en 2019, et elle n'est pas la seule à toucher un composant de base d'un serveur Linux ces dernières semaines (voir notre actualité sur OpenSSH 10.6p2). Un serveur qui attend qu'un administrateur lise les bulletins finit par rater une mise à jour. Trois mesures réduisent ce délai de façon durable :

1. Activer les mises à jour de sécurité automatiques. Sur Ubuntu, unattended-upgrades est installé et actif par défaut depuis la 16.04 LTS et applique les correctifs de sécurité dans les 24 heures. Sur Debian, le paquet s'installe et se configure en quelques minutes : notre guide automatiser les mises à jour de sécurité sur un VPS couvre les deux distributions. Comme cet outil passe lui aussi par libapt-pkg, des dépôts en HTTPS protègent sa première exécution après la publication d'un correctif.
2. S'abonner aux annonces de sécurité. La liste debian-security-announce et les avis USN de Canonical publient chaque correctif avec la version de paquet corrigée, ce qui permet de vérifier un serveur en une commande.
3. Réduire la surface d'attaque réseau. Un serveur dont l'accès SSH est limité par clé et par adresse IP (voir sécuriser SSH sur un VPS Linux) et dont les dépôts sont en HTTPS laisse peu de place à un attaquant pour se placer entre le serveur et ses mises à jour.

Sur un VPS Linux KVM ou un serveur dédié ElypseCloud, vous disposez de l'accès root et du choix de la distribution : appliquer un correctif d'APT, basculer les sources en HTTPS ou reconstruire une image prend quelques minutes, sans attendre l'intervention d'un tiers. Un serveur Debian 11 ou Ubuntu 20.04 hérité d'une ancienne installation est l'occasion de réinstaller sur une version LTS suivie, et d'en profiter pour appliquer les réglages de base d'un serveur neuf.