Faille APT sur Debian et Ubuntu : le gestionnaire de mises à jour peut installer un paquet piégé
Ce que dit la faille CVE-2026-109518, les versions corrigées de Debian et les vérifications à faire sur vos serveurs Linux
Image générée par IA (art. 50 AI Act)
Analyse 2LKATIME
Le 4 novembre, Debian a annoncé une faille dans APT, l'outil qui installe les mises à jour sur Debian et Ubuntu. Si APT est piégé, chaque mise à jour devient un risque. Aucune attaque n'est signalée à ce jour, mais le correctif existe : cet article explique comment vérifier votre version et corriger. Il complète nos articles sur les failles PHP.
Le serveur fait confiance à ses mises à jour
APT s'exécute avec les droits d'administrateur. Un paquet piégé installé par lui s'exécute lui aussi avec ces droits : l'attaquant prend le contrôle complet de la machine, sans passer par votre site ni vos mots de passe.
La faille porte la référence CVE-2026-109518. D'après Cyber Security News, qui cite Debian, un attaquant placé entre votre machine et le serveur de paquets peut remplacer un paquet vérifié par une version modifiée, juste après la vérification de sa signature.
Une précision sur nos sources : au moment de la rédaction, nous n'avons pas pu consulter l'avis de Debian en ligne. Les numéros de version ci-dessous viennent de la presse spécialisée. Contrôlez-les sur le Debian Security Tracker avant de décider.
1. Ce que dit l'alerte
4 nov.
Divulgation par Debian de la faille CVE-2026-109518
2.6.2
Version d'APT corrigée sur Debian 12 (2.6.1 vulnérable)
3.0.4
Version d'APT corrigée sur Debian 13 (3.0.3 vulnérable)
0
Exploitation publique signalée au 4 novembre
APT vérifie chaque paquet à partir de données signées avant de l'installer. La faille contourne cette vérification. Quand une redirection HTTP envoie deux téléchargements vers la même adresse, APT peut les fusionner. Lors de la reprise d'un téléchargement interrompu, il traite le fichier de façon incorrecte, ce qui ouvre une courte fenêtre pour remplacer le paquet après sa vérification. Le paquet installé est alors celui de l'attaquant.
Le chercheur Max Justicz est cité comme l'auteur de la découverte. Il avait déjà trouvé en 2019 une faille d'APT de même famille, liée aux redirections (CVE-2019-3462). Ce n'est pas le même bug, mais la leçon se répète : les redirections et la gestion des téléchargements sont des zones à risque pour un outil de mise à jour.
2. Pourquoi ce n'est pas une urgence de panique
L'attaque n'est pas déclenchable à distance par n'importe qui. Elle demande plusieurs conditions réunies, ce qui explique que la gravité soit moindre qu'une faille exploitable directement depuis Internet.
Un attaquant sur le chemin réseau
Réseau local, proxy, routeur piraté ou miroir de paquets malveillant. Sans cette position, l'attaque n'est pas possible.
Les redirections HTTP actives
L'attaque s'appuie sur une redirection qui amène deux téléchargements vers la même adresse. APT les suit par défaut.
Les nouvelles tentatives de téléchargement
Le réglage Acquire::Retries doit être supérieur à zéro. D'après l'article cité, il vaut 3 par défaut sur Debian 12 et sur Ubuntu 22.04.
Une reprise de téléchargement interrompu
C'est le moment où le fichier peut être remplacé après la vérification de signature, puis installé tel quel.
En pratique, un serveur hébergé chez un fournisseur et qui interroge un miroir officiel est peu exposé. Le risque grimpe pour un portable utilisé sur un Wi-Fi public, pour un serveur qui passe par un proxy ou un miroir mal maîtrisé, et pour un réseau dont le routeur est compromis. Ces scénarios existent, d'où l'intérêt de corriger.
3. Les versions concernées
Votre système est protégé si la version d'APT installée est égale ou supérieure à la version corrigée de votre distribution.
| Distribution | Version vulnérable | Version corrigée |
|---|---|---|
| Debian 12 (bookworm) | 2.6.1 | 2.6.2 |
| Debian 13 (trixie) | 3.0.3 | 3.0.4 |
| Debian testing et unstable | 3.3.5 | Pas de version corrigée indiquée dans l'article cité |
| Ubuntu | Variable | Correctifs Ubuntu propres : suivre l'avis USN |
Sur Ubuntu, ne comparez pas le numéro d'APT à celui de Debian. Les paquets d'Ubuntu portent leurs propres suffixes et leurs propres correctifs. Reportez-vous à l'avis USN correspondant. C'est la même logique que pour PHP, détaillée dans notre article sur PHP2Shell sur Ubuntu.
4. Vérifier et corriger
Connectez-vous au serveur et affichez la version d'APT, puis le paquet candidat à l'installation :
apt --version
apt-cache policy apt
Si la version installée est inférieure à la version corrigée, mettez APT à jour :
sudo apt update
sudo apt install --only-upgrade apt
apt --version
Faites d'abord cette opération depuis un réseau de confiance. Contrôlez ensuite d'où viennent vos paquets, pour repérer un miroir ou un proxy que vous ne reconnaissez pas :
grep -rhE "^(deb|URIs)" /etc/apt/sources.list /etc/apt/sources.list.d/
apt-config dump | grep -i -E "proxy|Retries"
Si vous ne pouvez pas mettre à jour tout de suite, une mesure provisoire consiste à désactiver les nouvelles tentatives, qui sont l'une des conditions de l'attaque. Les mises à jour deviennent moins fiables sur une connexion instable, donc retirez ce réglage dès que le correctif est installé :
echo 'Acquire::Retries "0";' | sudo tee /etc/apt/apt.conf.d/99-no-retries
Si les mises à jour automatiques sont activées (unattended-upgrades), vérifiez qu'elles ont bien tourné après la sortie du correctif :
grep -E "Start-Date|Upgrade:.* apt" /var/log/apt/history.log | tail -n 20
5. Réduire le risque durablement
Le correctif règle cette faille. La question de fond reste : quel chemin réseau emprunte la mise à jour de vos serveurs ? Quatre habitudes réduisent l'exposition à ce genre de problème.
Passer par des miroirs HTTPS officiels
deb.debian.org et les miroirs officiels d'Ubuntu acceptent HTTPS. Le chiffrement rend l'interception beaucoup plus difficile.
Éviter les proxys et miroirs inconnus
Un miroir « maison » ou un proxy d'entreprise mal tenu place un tiers sur le chemin de vos mises à jour. Gardez-les sous contrôle.
Ne pas mettre à jour sur un Wi-Fi public
Un portable Linux qui lance apt upgrade dans un café s'expose à ce type d'attaque. Utilisez un VPN ou attendez d'être sur un réseau de confiance.
Reconstruire vos images Docker
Les builds CI et les images Docker exécutent apt en root. Reconstruisez les images de base une fois APT corrigé, et faites tourner les builds sur un réseau maîtrisé.
6. Conformité
Appliquer les correctifs de sécurité fait partie des mesures attendues par l'article 32 du RGPD. Gardez une trace de la date de mise à jour et de la version installée sur chaque serveur. Les entités soumises à NIS2 doivent en plus démontrer une gestion des vulnérabilités suivie dans le temps. Un simple inventaire daté suffit souvent à prouver que vous avez agi.
7. Ce que 2LKATIME recommande
Faites l'inventaire de vos machines Debian et Ubuntu : serveurs, postes, conteneurs, runners de build. Notez la version d'APT, l'origine des paquets et l'état des mises à jour automatiques. Nos audits cybersécurité couvrent ce périmètre. Si vous gérez un site WordPress sur un VPS, relisez aussi notre article Faut-il couper son site en cas de faille critique ?.
Les entreprises de Paris, de Lyon ou de Bordeaux trouveront les formules sur nos pages tarifs. L'accompagnement se fait aussi à distance partout en France.
FAQ - Faille APT sur Debian et Ubuntu
Mon serveur Debian 12 est-il concerné ?
Selon le Debian Security Tracker tel que cité par la presse spécialisée, APT 2.6.1 est vulnérable sur Debian 12 et la version 2.6.2 est corrigée. Si apt --version affiche 2.6.1, mettez APT à jour. Vérifiez ces numéros sur le tracker de Debian, qui fait foi.
Faut-il être sur le même réseau que le serveur pour l'attaquer ?
Il faut se trouver sur le chemin entre le serveur et le miroir de paquets : réseau local, proxy, routeur compromis ou miroir malveillant. Un attaquant qui n'a aucune position sur ce chemin ne peut pas exploiter la faille, d'après la description publiée.
Faut-il désactiver les nouvelles tentatives de téléchargement ?
C'est une mesure provisoire, à utiliser seulement si vous ne pouvez pas mettre à jour tout de suite : mettre Acquire::Retries à 0 supprime l'une des conditions de l'attaque. Les mises à jour deviennent moins fiables sur une connexion instable. Appliquez le correctif dès que possible et retirez ce réglage ensuite.
Et sur Ubuntu ?
Ubuntu publie ses propres correctifs, avec ses propres numéros de version. Surveillez les avis de sécurité Ubuntu (USN) et comparez la version du paquet apt avec celle de l'avis, sans vous fier au numéro d'APT seul.
Y a-t-il des attaques en cours ?
Au 4 novembre, aucune exploitation publique n'est signalée par les sources que nous avons lues. La faille vient d'être divulguée : cela peut changer vite, d'où l'intérêt de corriger sans attendre.
Sources
Vos serveurs Linux sont-ils à jour, et d'où viennent leurs paquets ?
2LKATIME inventorie vos serveurs, contrôle les versions et l'origine des mises à jour, puis vous remet un rapport clair avec les actions à mener.