Une faille dans APT laisse un attaquant du réseau substituer un paquet vérifié et exécuter du code en root

4 novembre 2026. Debian publie la DSA-6607-1 et la DLA-4880-1 pour corriger CVE-2026-109518, une faille critique dans APT, le gestionnaire de paquets de Debian, Ubuntu et de leurs dérivés. 4 novembre 2026, 14 h 25 UTC. Ubuntu publie à son tour quatre correctifs dans son archive de sécurité. 4 novembre 2026, 15 h 46 UTC. Ubuntu maintient pourtant ses huit versions suivies — de 14.04 LTS à 26.10 — comme vulnérables le temps que les mises à jour se propagent. La faille tient en une phrase : un attaquant capable de modifier le trafic HTTP entre un hôte et son miroir de paquets peut remplacer un paquet déjà vérifié par le sien, et ce code s’exécute ensuite en root.

Pour un parc Debian ou Ubuntu qui passe par un proxy ou un miroir non maîtrisé, ce n’est pas un détail d’hygiène. C’est une compromission complète déclenchée par une simple installation de paquet. Et l’histoire de la faille — signalée par un chercheur, corrigée avant toute exploitation — en fait un cas d’école de divulgation coordonnée réussie.

La mécanique : le retry casse la vérification

Le cœur de la faille est dans la façon dont APT gère les téléchargements qui échouent. Depuis Debian 12 et Ubuntu 22.04, APT réessaie par défaut les téléchargements en échec, un comportement piloté par le paramètre Acquire::Retries. Ce réglage, censé rendre les installations plus robustes, ouvre une fenêtre : lors d’une reprise, APT réutilise une partie de l’état déjà validé sans re-vérifier ce qu’il reçoit.

Concrètement, l’attaquant — un miroir malveillant, un proxy compromis, ou n’importe qui en position on-path sur le chemin HTTP — combine des redirections HTTP et des erreurs temporaires ordinaires pour forcer APT à réessayer. Au moment du retry, il substitue le paquet légitime par un paquet malveillant. APT l’installe comme s’il avait passé la vérification de signature, et le code — typiquement un script postinst — s’exécute avec les privilèges root.

Le point d’entrée est trivial à comprendre pour un opérateur : le flux HTTP est en clair par défaut sur la plupart des configurations Debian et Ubuntu. Les dépôts officiels sont accessibles en HTTP, et la signature GPG des paquets est précisément ce qui doit compenser l’absence de chiffrement. La faille contourne cette compensation : elle n’a pas besoin de casser une clé, elle exploite le moment où APT ne re-vérifie pas.

# Vérifier le réglage de retry sur un hôte :
apt-config dump | grep -i 'Acquire::Retries'

# Mettre à jour apt immédiatement, avant tout autre correctif :
apt-get update
apt-get install --only-upgrade apt

L’enjeu n’est pas théorique. Un paquet installé en root peut poser un backdoor, modifier des binaires système ou exfiltrer des secrets. Pour un serveur de production ou une machine de build, c’est la compromission complète de la chaîne d’approvisionnement logicielle.

Qui est exposé, qui ne l’est pas

Le périmètre est plus subtil qu’un simple « tout le monde ». Debian et Ubuntu ont chacun publié une cartographie précise.

• Debian : bookworm (12) passe de la 2.6.1 à la 2.6.2 (DLA-4880-1), trixie (13) de la 3.0.3 à la 3.0.4 (DSA-6607-1), et sid reçoit la 3.3.6. Au moment de la publication, la branche testing (forky) tournait encore sur la 3.3.5 vulnérable.
• Ubuntu : correctifs publiés à 14 h 25 UTC pour 26.10 (3.3.3ubuntu0.1), 26.04 LTS (3.2.1ubuntu0.1), 24.04 LTS (2.8.4ubuntu0.1) et 22.04 LTS (2.4.15ubuntu0.1). Ubuntu Pro couvre déjà 14.04 LTS.
• Debian 11 et Ubuntu 20.04 ne sont pas exposées par défaut, car le retry automatique y est désactivé. Mais APT prévient : de nombreux scripts d’exploitation activent Acquire::Retries manuellement sur ces versions, ce qui les rend vulnérables quand même.

Ubuntu évalue la faille en haute priorité avec un score CVSS 4.0 de 7,7, et précise que toutes les distributions construites sur Debian ou Ubuntu sont concernées, sans les nommer.

Un point mérite l’attention : aucun des trois avis — Debian, Ubuntu, APT — ne décrit d’exploitation en cours. La faille a été signalée par Max Justicz dans le cadre d’une divulgation coordonnée. Pour l’instant, le correctif précède l’exploitation publique ; c’est exactement la fenêtre pendant laquelle un parc doit patcher avant que le premier exploit ne circule.

Ce qu’il faut faire

La réponse tient en trois gestes, par ordre de priorité.

• Mettre à jour apt partout, maintenant. La correction ne dépend d’aucune autre dépendance : c’est le paquet apt lui-même qui change. Déployez-le en premier, avant tout autre correctif.
• Repasser les sources en HTTPS. La faille est décrite sur HTTP, et les avis ne tranchent pas encore sur l’exposition des sources en HTTPS. Même si HTTPS ne suffit pas toujours — un miroir compromis peut rester en HTTPS — il supprime la classe d’attaquants qui se contentent d’être on-path sur le réseau.
• Auditer Acquire::Retries et vos miroirs. Sur les versions anciennes où le retry est désactivé par défaut, vérifiez qu’aucun script ne l’a réactivé. Et recensez vos miroirs internes et proxys : un attaquant qui tient votre proxy tient désormais votre chaîne d’installation.

Il n’existe aucun contournement documenté pour les systèmes qui ne peuvent pas mettre à jour immédiatement — les trois avis sont explicites sur ce point. Pour ces machines, le seul levier restant est au niveau réseau : figer vos sources sur des miroirs de confiance, désactiver le retry (Acquire::Retries "0"), et, si votre infrastructure le permet, forcer le trafic APT à passer par un proxy HTTPS de confiance que vous contrôlez. Ce sont des palliatifs, pas des correctifs : la seule vraie sortie reste la mise à jour d’apt.

Comment vérifier que vous êtes corrigé

Une fois la mise à jour appliquée, deux vérifications rapides confirment que le correctif est bien actif.

# Version du paquet apt (>= 2.6.2, 3.0.4 ou 3.3.6 selon la branche) :
apt-cache policy apt

# S'assurer qu'aucun retry forcé ne traîne dans la configuration :
apt-config dump | grep -i 'Acquire::Retries'

Au-delà de la version, gardez en tête ce que la faille ne change pas : APT reste un composant de confiance. Le corriger ne dispense ni de surveiller vos journaux (/var/log/apt/history.log), ni de verrouiller vos miroirs avec des dépôts signés et des listes de sources maîtrisées. Une chaîne d’installation est un ensemble : le gestionnaire de paquets n’en est que le premier maillon. Cette faille appartient d’ailleurs à la famille des TOCTOU — time-of-check to time-of-use — où la vérification et l’utilisation d’une donnée sont séparées par une fenêtre qu’un attaquant peut exploiter ; c’est une classe récurrente, et le correctif du jour n’en éteint pas la cause générique.

Verdict

Cette faille rappelle pourquoi la signature des paquets n’est pas une option mais un pilier, et pourquoi un pilier peut se fissurer d’un coup sur un simple défaut de re-vérification. Le correctif est simple à appliquer, et aucune exploitation n’est documentée à ce jour : la fenêtre pour patcher proprement est ouverte.

Si vous gérez un parc Debian ou Ubuntu, mettez à jour apt dès aujourd’hui et basculez vos sources en HTTPS ; le coût est une commande, le risque évité est la compromission root de toute la chaîne d’installation. Si vous maintenez un miroir ou un proxy interne, traitez-le comme une surface d’attaque : c’est désormais l’équivalent d’une machine qui distribue des binaires à tout votre parc. La vraie question n’est plus « est-ce que je suis exposé », mais « est-ce que mon apt est déjà à jour ».

Références

• The Hacker News — Debian and Ubuntu APT Flaw Lets MitM Attackers Swap Verified Packages and Run Code as Root (4 novembre 2026)
• Debian Security Tracker — CVE-2026-109518
• Ubuntu Security — CVE-2026-109518