Faille APT CVE-2026-109518 : vérifier, corriger

Faille APT CVE-2026-109518 : que faire maintenant ?

La faille APT CVE-2026-109518 permet à un attaquant placé sur le trajet HTTP, ou à un miroir malveillant, de faire installer un paquet non vérifié. Le code de ce paquet s'exécute alors en root. Regardez d'abord votre version d'APT, puis comparez-la à la liste ci-dessous. Si votre version est plus ancienne, installez le correctif avec Acquire::Retries=0.

Ubuntu classe cette faille au niveau High, avec un score CVSS v4.0 (Common Vulnerability Scoring System) de 7,7. Debian et Ubuntu ont publié leurs correctifs le 4 novembre 2026.

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

Le motif ?source-package(^apt$) sélectionne les paquets construits à partir du paquet source apt. Vous pouvez donc voir plusieurs lignes. Lisez le numéro de version sur chaque ligne et comparez-le à celui de votre système :

• Debian 13 (trixie) : 3.0.4, avis DSA-6607-1
• Debian 12 (bookworm) : 2.6.2, avis DLA-4880-1
• Ubuntu 26.10 : 3.3.3ubuntu0.1
• Ubuntu 26.04 LTS : 3.2.1ubuntu0.1
• Ubuntu 24.04 LTS : 2.8.4ubuntu0.1
• Ubuntu 22.04 LTS : 2.4.15ubuntu0.1
• Ubuntu 20.04 LTS : 2.0.12+esm1, avec Ubuntu Pro
• Ubuntu 18.04 LTS : 1.6.19+esm1, avec Ubuntu Pro
• Ubuntu 16.04 LTS : 1.2.36+esm1, avec Ubuntu Pro et le module Legacy
• Ubuntu 14.04 LTS : 1.0.1ubuntu2.24+esm4, avec Ubuntu Pro et le module Legacy

Les sources sont l'avis USN-8996-1 (Ubuntu Security Notice), l'avis DSA-6607-1 (Debian Security Advisory) et l'avis DLA-4880-1 (Debian LTS Advisory). Debian 12 reçoit un DLA et non un DSA parce que cette version est en phase LTS (long term support) depuis le 12 juillet 2026.

La page de manuel apt-patterns(7) indique que les motifs existent depuis APT 2.0. Sur un système plus ancien, comme Ubuntu 18.04, la commande ci-dessus peut donc échouer. Utilisez plutôt celle-ci, qui affiche la version installée et la version candidate :

apt-cache policy apt

Comment corriger APT sans passer par la faille

Ubuntu recommande d'abord une mise à jour complète, avec les nouvelles tentatives désactivées :

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

Si une mise à jour complète n'est pas possible sur ce serveur, Ubuntu publie une commande qui met à jour APT seul :

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

Ces commandes viennent du billet de sécurité d'Ubuntu. Les avis de Debian ne donnent pas de commande équivalente. L'option -o et le motif appartiennent à APT et non à Ubuntu, donc la même ligne convient à Debian 12 et 13. Sur un APT trop ancien pour les motifs, nommez le paquet :

sudo apt-get install -o Acquire::Retries=0 --only-upgrade apt

Relancez ensuite apt list --installed '?source-package(^apt$)'. Le numéro affiché doit être égal à la version corrigée de votre système, ou plus récent. S'il n'a pas changé, ne considérez pas le serveur comme corrigé. Lisez apt-cache policy apt : si aucune version candidate corrigée n'apparaît, vos sources ne proposent pas encore le correctif. Si apt signale des paquets cassés, suivez la réparation des paquets cassés sur Ubuntu et Debian avant de recommencer.

Pourquoi mettre les nouvelles tentatives à zéro ?

Le correctif arrive par le client qui contient la faille. Le téléchargement du nouvel APT est fait par l'ancien APT, donc il passe par le code vulnérable. La faille a besoin des nouvelles tentatives de téléchargement. Ubuntu indique que Acquire::Retries à zéro pendant l'installation de cette mise à jour protège contre un attaquant sur le trajet et contre un miroir malveillant.

Cette option doit rester temporaire, selon Ubuntu. Avec -o, elle s'applique à la commande que vous lancez et ne modifie aucun fichier de configuration. Vous n'avez donc rien à annuler. Sans nouvelle tentative, une erreur réseau passagère fait échouer le téléchargement. Dans ce cas, relancez la commande.

Comment fonctionne la faille APT ?

L'avis amont APT-2026-11-01 décrit le problème. Un attaquant distant utilise des redirections HTTP et des erreurs serveur passagères qui provoquent de nouvelles tentatives de téléchargement. APT écrase alors des liens physiques existants avec un contenu choisi par l'attaquant. La vérification des paquets téléchargés est contournée.

Un lien physique (hard link) est un deuxième nom pour le même contenu sur le disque. Si un programme ouvre un fichier existant et le modifie, le contenu change sous tous ses noms. C'est le point de départ du commit de correction, qui explique que modifier un fichier existant peut avoir un effet inattendu si ce fichier est un lien physique.

L'avis Debian ajoute deux détails. Une redirection HTTP peut donner le même URI à deux téléchargements différents, et APT peut alors les fusionner. Ensuite, une mauvaise gestion des fichiers à la reprise d'un téléchargement HTTP permet de remplacer un paquet après sa vérification. Les paquets .deb s'installent avec les droits root, donc le code de l'attaquant s'exécute en root.

Le correctif change la façon d'écrire. APT ouvre maintenant les fichiers cibles de manière exclusive. Pour reprendre un téléchargement, il lit le fichier existant, supprime l'ancien nom, crée un nouveau fichier et y copie le contenu. Le lien physique n'est donc plus modifié.

Votre serveur est-il exposé ?

La faille demande une valeur non nulle pour Acquire::Retries. Cette valeur est 3 par défaut depuis APT 2.3.2, donc depuis Debian 12 et Ubuntu 22.04. Ces versions sont exposées dans leur configuration normale.

Les versions plus anciennes ne sont exposées que si quelqu'un a défini cette option. L'avis amont rappelle que beaucoup de scripts ont pu le faire. Ne supposez donc rien sur un vieux serveur que vous n'avez pas installé vous-même. Vérifiez :

apt-config dump | grep -i retries

Lisez le résultat de cette façon :

• Une ligne apparaît : elle donne la valeur configurée. Toute valeur différente de 0 expose le serveur tant qu'APT n'est pas corrigé.
• Rien n'apparaît sur APT 2.3.2 ou plus récent : votre serveur n'est pas protégé pour autant. L'option n'est simplement pas écrite dans la configuration, et la valeur intégrée de 3 s'applique.
• Rien n'apparaît sur un APT plus ancien que 2.3.2 : l'option n'est pas définie, ce qui correspond au cas non exposé par défaut.

Le deuxième cas vient du code source. Dans la version 2.6.2 et dans la branche principale, APT lit l'option avec FindI("Acquire::Retries", 3). Le 3 est une valeur de repli dans le code, et nous n'avons pas trouvé d'endroit où APT l'enregistre dans sa configuration. C'est pourquoi apt-config dump peut ne rien afficher. Nous ne publions pas de sortie type, car nous n'avons pas exécuté cette commande sur chaque version. Fiez-vous à ce que votre serveur affiche.

La faille touche le moteur HTTP d'APT. Elle concerne donc apt, apt-get, aptitude et les outils graphiques basés sur APT. Ubuntu précise que les paquets snap et le transport FTP ne sont pas touchés.

HTTPS protège-t-il contre la faille APT ?

En partie. Le correctif reste l'APT à jour, et HTTPS est un renforcement.

Ubuntu écrit que TLS (transport layer security) via HTTPS protège contre cette faille, car l'exploitation demande de manipuler le trafic HTTP. Ubuntu écrit aussi qu'un miroir malveillant peut exploiter la faille de la même façon. Notre lecture de ces deux phrases : HTTPS arrête un attaquant sur le trajet, mais il n'arrête pas un miroir malveillant, car ce miroir est l'autre bout de la connexion chiffrée. Une fois le client APT à jour, Ubuntu indique que ce risque disparaît.

Les avis de Debian ne parlent pas de HTTPS. Ne tirez donc aucune conclusion de cette section pour un dépôt Debian.

Passer les sources Ubuntu en HTTPS, y compris fr.archive.ubuntu.com

Gardez d'abord une copie de vos sources, car la commande suivante modifie les fichiers sur place :

sudo cp -a /etc/apt /root/apt-avant-https

Ubuntu publie ensuite cette commande :

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

La partie ([a-z]+\.)? accepte un préfixe de pays. Le motif couvre donc aussi fr.archive.ubuntu.com, l'hôte que beaucoup de serveurs en France utilisent. Si l'un des chemins n'existe pas sur votre serveur, sed signale ce fichier et continue avec les autres. Ce message n'est pas grave en lui-même.

Ubuntu précise que la commande ne modifie pas les URL des autres miroirs et dépôts. Elle ne touche donc pas ubuntu.mirrors.ovh.net, par exemple. Regardez ce qui reste en HTTP :

grep -rn 'http://' /etc/apt/sources.list /etc/apt/sources.list.d/

Ignorez les lignes de commentaire. Pour les autres lignes, décidez au cas par cas, car Ubuntu avertit que certains miroirs communautaires, dont certains miroirs de pays, n'ont pas HTTPS. Sur un tel miroir, apt update affiche une erreur après le passage en HTTPS. Le 5 novembre 2026, le fichier Release de noble s'est chargé en HTTPS sur fr.archive.ubuntu.com et sur ubuntu.mirrors.ovh.net. Ce test montre que ces deux hôtes répondent en HTTPS. Il ne dit rien de leur fraîcheur.

Nous n'avons pas vérifié les URL utilisées par défaut dans les images actuelles d'OVHcloud ou de Scaleway. Lisez vos propres sources, puis confirmez avec sudo apt update. En cas d'erreur, corrigez la ligne concernée ou restaurez votre copie.

Unattended-upgrades a-t-il vraiment appliqué le correctif ?

Ubuntu indique que unattended-upgrades est activé par défaut depuis 16.04 LTS et qu'il applique ces correctifs dans les 24 heures, s'il est activé. Cette phrase ne prouve rien pour votre serveur. Vérifiez le journal, puis la version :

sudo grep -w 'apt' /var/log/unattended-upgrades/unattended-upgrades-dpkg.log | tail -n 20
sudo tail -n 30 /var/log/unattended-upgrades/unattended-upgrades.log
apt list --installed '?source-package(^apt$)'

Le premier fichier contient la sortie de dpkg. Le deuxième contient toutes les opérations du service. Les journaux disent ce que le service a fait. La preuve finale reste le numéro de version de la dernière commande. Vous n'êtes pas obligé d'attendre le passage du service : la commande manuelle ci-dessus est immédiate.

Si le service ne tourne pas, consultez la configuration d'unattended-upgrades sur Ubuntu. Sur Debian, nous ne donnons pas de comportement par défaut ici, mais le diagnostic d'unattended-upgrades qui ne tourne pas sur Debian vous aide à contrôler votre serveur.

Le correctif LTS a-t-il atteint YunoHost sur Debian 12 ?

Au 5 novembre 2026, nous n'avons trouvé aucune annonce de YunoHost sur cette faille. Le script d'installation de la version stable de YunoHost ne fonctionne que sur Debian 12. Il ajoute son propre dépôt et ne modifie pas security.debian.org. APT vient donc des sources Debian de la machine. La page du paquet Debian montre apt 2.6.2 dans la section de sécurité de bookworm.

Un YunoHost sur un Debian 12 normal, avec la source de sécurité standard, peut donc recevoir 2.6.2. Ne le supposez pas pour votre machine. Contrôlez :

apt-cache policy apt

Le dépôt du script d'installation contient aussi un script trixie pour Debian 13, mais il refuse la branche stable et n'accepte que testing et unstable. Sur un YunoHost installé ainsi, comparez avec 3.0.4 et non avec 2.6.2.

La documentation de YunoHost indique que yunohost tools update puis yunohost tools upgrade system mettent à jour les paquets système. Pour passer Acquire::Retries=0, utilisez plutôt la ligne apt avec --only-upgrade, car c'est elle qui porte l'option.

Qu'a publié Proxmox VE pour ses hôtes ?

Au 5 novembre 2026, le fil des avis de sécurité Proxmox VE ne contenait aucun avis sur APT. Son avis le plus récent était PSA-2026-00085-1, daté du 3 novembre 2026. Consultez ce fil à nouveau, car il peut changer.

La documentation Proxmox indique que PVE 9 repose sur Debian trixie et demande les dépôts Debian de base, dont trixie-security. Nous en déduisons qu'un hôte PVE 9 reçoit APT 3.0.4 par le dépôt de sécurité Debian, sauf si ses sources sont différentes. Proxmox n'a pas écrit cela. Lancez apt-cache policy apt sur l'hôte. Si /etc/os-release indique Debian 13, comparez avec 3.0.4. S'il indique Debian 12, comparez avec 2.6.2.

Faut-il reconstruire les images FROM debian et FROM ubuntu ?

Oui, si votre Dockerfile ou votre conteneur lance apt. Une image déjà construite garde la version d'APT qu'elle contenait, et tout apt-get install lancé avec cette version passe par le code vulnérable.

Voici l'état lu sur Docker Hub le 5 novembre 2026 :

• debian:bookworm et debian:trixie ont été publiées le 5 novembre. La branche d'artefacts de Debian liste apt 2.6.2 et 3.0.4, soit les versions corrigées. Nous n'avons pas inspecté les images elles-mêmes.
• ubuntu:22.04, ubuntu:24.04 et ubuntu:26.04 ont été publiées pour la dernière fois le 29 octobre, avant le correctif. Elles ne peuvent donc pas le contenir à cette date.

Contrôlez l'image que vous utilisez :

docker pull debian:trixie
docker run --rm debian:trixie apt list --installed '?source-package(^apt$)'

Tant que la base Ubuntu n'est pas reconstruite, corrigez APT dans la première étape, avant tout autre paquet :

FROM ubuntu:24.04
RUN apt-get update \
 && apt-get install -y -o Acquire::Retries=0 --only-upgrade apt

Reconstruisez ensuite sans cache, en demandant la dernière base :

docker build --pull --no-cache -t mon-image .

--pull tente toujours de récupérer les images citées, et --no-cache empêche la réutilisation d'une ancienne couche. Sans --no-cache, Docker peut reprendre une couche construite avant le correctif.

Debian 11, 10 et 9 : où est le correctif ?

Freexian a publié l'avis ELA-1880-1 le 4 novembre 2026. Les versions corrigées sont 2.2.5 pour Debian 11, 1.8.2.4 pour Debian 10 et 1.4.12 pour Debian 9. Ces paquets sont dans un dépôt privé réservé aux abonnés de l'offre payante Extended LTS, selon la page de Freexian. Le wiki Debian donne le 31 août 2026 comme fin du LTS de Debian 11.

Ces versions ne sont exposées que si Acquire::Retries a été défini. Sans abonnement, la bonne décision à long terme est de changer de version, et le chemin de mise à niveau depuis Debian 11 décrit les étapes.

La faille est-elle exploitée ? État au 5 novembre 2026

Le billet d'Ubuntu, l'avis USN et les avis Debian ne disent pas si la faille est exploitée. Nous ne l'affirmons donc pas non plus.

• CISA KEV (Known Exploited Vulnerabilities) : CVE-2026-109518 n'apparaît pas dans les entrées les plus récentes que nous avons lues, pour le catalogue 2026.11.04. Nous n'avons pas lu tout le fichier. Cherchez la CVE dans le catalogue.
• CERT-FR : la première page des avis, datés du 4 novembre 2026, ne contenait aucun avis sur APT, Debian ou Ubuntu. Revérifiez sur cert.cyber.gouv.fr.

Une version corrigée ne prouve pas qu'un serveur n'a pas été touché avant le correctif. Si vous voyez un comportement anormal, suivez la procédure à appliquer quand un VPS est piraté. Pour suivre les prochaines failles de la même façon, gardez une méthode pour vérifier les CVE connues sur votre serveur.

Ce qu'une signature de paquet garantit vraiment

Une signature de dépôt dit qu'un fichier est bien celui que le dépôt a publié. Elle ne protège que ce que le client vérifie, au moment où il le vérifie. Dans cette faille, le paquet peut être remplacé après la vérification. Ubuntu résume ainsi l'effet : APT installe un paquet même s'il échoue à la vérification de signature.

La leçon vaut pour les prochaines failles. La chaîne de confiance comprend aussi le programme qui fait la vérification. Un dépôt signé ne vous protège pas d'un bug dans ce programme, donc APT doit recevoir ses mises à jour de sécurité aussi vite que le noyau ou OpenSSH. HTTPS réduit le nombre de personnes qui peuvent toucher votre trafic. Un miroir reste un tiers, et c'est la signature, vérifiée par un client sain, qui rend ce tiers acceptable.

FAQ

Comment savoir si mon serveur est touché par la faille APT CVE-2026-109518 ?

Lancez apt list --installed '?source-package(^apt$)' et comparez la version avec celle de votre système. Les versions corrigées sont 3.0.4 pour Debian 13, 2.6.2 pour Debian 12, 2.4.15ubuntu0.1 pour Ubuntu 22.04, 2.8.4ubuntu0.1 pour Ubuntu 24.04, 3.2.1ubuntu0.1 pour Ubuntu 26.04 et 3.3.3ubuntu0.1 pour Ubuntu 26.10. Une version plus ancienne signifie que le serveur n'est pas corrigé.

Pourquoi utiliser Acquire::Retries=0 pour installer le correctif ?

Le nouvel APT est téléchargé par l'ancien APT, qui contient la faille. L'attaque a besoin des nouvelles tentatives de téléchargement. Ubuntu indique que mettre Acquire::Retries à zéro pendant cette installation protège contre un attaquant sur le trajet et contre un miroir malveillant. Passez l'option avec -o sur la ligne de commande, car Ubuntu demande de ne l'utiliser que temporairement.

Est-ce que HTTPS suffit à me protéger de cette faille APT ?

Non. Ubuntu écrit que HTTPS protège contre la manipulation du trafic HTTP, et aussi qu'un miroir malveillant peut exploiter la faille. HTTPS bloque donc l'attaquant sur le trajet, pas le miroir lui-même. Les avis de Debian ne parlent pas de HTTPS. Installez la version corrigée d'APT dans tous les cas, puis ajoutez HTTPS comme renforcement.

Mon serveur Ubuntu 20.04 est-il concerné ?

Par défaut, non : Ubuntu indique que Acquire::Retries n'a une valeur non nulle par défaut que depuis Ubuntu 22.04. Il est exposé si cette option a été définie, ce que vous pouvez contrôler avec apt-config dump | grep -i retries. Le correctif pour 20.04 est la version 2.0.12+esm1, disponible avec Ubuntu Pro. Le fonctionnement d'Ubuntu Pro sur un serveur explique comment l'activer. La page Ubuntu Pro annonce la gratuité pour un usage personnel sur 5 machines physiques au maximum. Pour une entreprise, lisez les conditions sur cette page.

La commande apt-config dump n'affiche rien. Suis-je protégé ?

Non, pas sur APT 2.3.2 ou plus récent. Dans le code d'APT, la valeur 3 est une valeur de repli, donc elle peut ne pas apparaître dans apt-config dump. Un résultat vide signifie que l'option n'est pas écrite dans la configuration. Sur ces versions, seule la version corrigée d'APT vous protège.