APT : RCE par échange de paquet en root sur Debian et Ubuntu (CVE-2026-109518)

En bref

• APT peut être amené à installer un paquet fourni par l'attaquant à la place de celui qu'il a vérifié. Un miroir ou un proxy malveillant sur le chemin réseau déclenche la faille pendant une installation de paquet.
• Debian 12 et les versions suivantes, Ubuntu 22.04 et les versions suivantes, ainsi que les dérivées qui héritent de leur configuration APT, ont les nouvelles tentatives activées par défaut. Debian 11 et Ubuntu 20.04 ne sont exposés que si les nouvelles tentatives ont été activées.
• Ubuntu note la faille 7,7 High en CVSS v4.0. CVE-2026-109518 n'est pas au catalogue KEV de la CISA au 5 novembre 2026, et aucune exploitation n'est connue.
• Mettez à jour APT vers la version corrigée de votre distribution. Si la mise à jour n'est pas possible tout de suite, réglez Acquire::Retries "0" comme mesure provisoire ; voir « Comment corriger ? ».

Suis-je concerné ?

Toutes ces conditions doivent être réunies pour qu'un système soit exposé :

• La version d'APT de la machine est antérieure à la version corrigée de sa distribution.
• La machine installe des paquets par un chemin réseau qu'un attaquant peut modifier, comme un miroir HTTP ou un proxy.
• Acquire::Retries n'est pas à zéro. La valeur par défaut est 3 depuis Debian 12 et Ubuntu 22.04, donc les versions plus anciennes ne sont pas exposées dans une configuration par défaut.
• Une installation de paquet a lieu pendant que l'attaquant est sur ce chemin, et APT suit une redirection puis réessaie un téléchargement.

Les URL d'archive par défaut de Debian et d'Ubuntu utilisent HTTP, et un attaquant sur le chemin peut modifier les réponses. Les avis décrivent l'attaque en HTTP. Ils ne précisent pas si les sources accédées en HTTPS sont exposées. Debian 11 et Ubuntu 20.04 ne sont pas concernés par défaut, mais des scripts peuvent y avoir activé les nouvelles tentatives.

Debian 11 est au-delà de sa fenêtre de support à long terme, et le suivi Debian n'y liste aucun paquet corrigé. L'enregistrement CVE donne 2.2.5 comme première version corrigée de la branche 2.2.x. Vérifiez la version installée :

apt --version
dpkg-query -W -f='${Version}\n' apt

apt --version affiche une ligne comme apt 3.0.3 (amd64). Comparez la version installée complète avec la version corrigée de votre distribution : 3.0.3 est antérieure à la version corrigée 3.0.4. Un rétroportage peut porter une chaîne de version différente ; si la version semble antérieure au tableau, vérifiez l'avis de sécurité de la distribution avant de conclure que la machine n'est pas corrigée.

Comment corriger ?

Comme la mise à jour passe elle-même par APT, appliquez d'abord la mesure provisoire, puis mettez à jour, puis décidez si vous la conservez.

1. Créez le réglage des nouvelles tentatives. Il supprime la nouvelle tentative dont l'attaque a besoin.

bash printf 'Acquire::Retries "0";\n' | sudo tee /etc/apt/apt.conf.d/99-no-retries sudo apt-config dump | grep -i 'Acquire::Retries'

La seconde commande affiche Acquire::Retries "0"; lorsque le fichier est lu.

1. Mettez à jour APT sur Debian :

bash sudo apt update sudo apt install --only-upgrade apt

1. Mettez à jour APT sur Ubuntu, y compris les versions ESM où le paquet est disponible avec Ubuntu Pro :

bash sudo apt update sudo apt install --only-upgrade apt

1. Confirmez la nouvelle version avec apt --version, puis répétez sur chaque machine et chaque image de conteneur qui installe des paquets.

2. Conservez /etc/apt/apt.conf.d/99-no-retries ou supprimez-le après la mise à jour. Le supprimer rétablit le comportement de nouvelle tentative par défaut, et la protection repose alors sur APT corrigé.

L'avis Debian est DSA-6607-1 et l'avis Ubuntu est USN-8996-1. Le correctif est le commit « methods: Open target files exclusively ».

Les limites de la mesure provisoire :

1. Elle empêche APT de réessayer un téléchargement échoué, ce qui est l'étape dont l'attaque a besoin. Le fil de divulgation la décrit comme une atténuation en attendant la mise à jour.
2. Elle coûte de la résilience. Une erreur passagère d'un miroir fait désormais échouer l'installation au lieu de réessayer, donc un miroir surchargé ou peu fiable produira plus d'échecs.
3. Elle ne rend pas le code de téléchargement sûr. L'écriture sur place reste dans le binaire, et tout futur chemin qui reprend un téléchargement sans nouvelle tentative n'est pas couvert.

La mesure provisoire couvre uniquement CVE-2026-109518. Elle ne traite pas les autres failles corrigées dans les mêmes versions d'APT.

Quelle est la cause racine ?

APT est le gestionnaire de paquets qui résout les dépendances, télécharge les fichiers .deb et les confie à dpkg. Sa méthode HTTP écrit chaque téléchargement dans un fichier de destination dérivé de l'URI de la requête. Lors d'une reprise, elle ouvre ce fichier et écrit à un décalage donné.

Le code vulnérable ouvrait la destination sans indicateur de création exclusive. L'extrait concerné de methods/http.cc avant le correctif est :

auto ret = BaseHttpMethod::DealWithHeaders(Res, Req);
if (ret != BaseHttpMethod::FILE_IS_OPEN)
   return ret;
if (Req.File.Open(Queue->DestFile, FileFd::WriteAny) == false)
   return ERROR_NOT_FROM_SERVER;

Queue->DestFile est le chemin local du téléchargement. Req.StartPos est le décalage de reprise en octets. FileFd::WriteAny ouvre un fichier existant en écriture et le crée s'il manque, mais il n'exige pas que le fichier soit neuf. L'ouverture suit donc une entrée de répertoire existante et écrit dans son inode. Un lien matériel ou un lien symbolique à ce chemin est suivi plutôt que remplacé.

L'avis Debian décrit la conséquence : APT peut fusionner deux téléchargements de paquets différents lorsqu'une redirection HTTP leur donne la même URI. Les deux files utilisent alors un seul fichier de destination. Quand un téléchargement reprend, ses octets sont écrits dans le fichier que l'autre file a déjà vérifié. Le paquet que dpkg installe n'est pas celui dont APT a contrôlé le hachage.

Comment la faille est-elle exploitée ?

1. L'attaquant prend position sur le chemin entre le client APT et l'archive, par exemple un miroir malveillant, un proxy ou un segment réseau qu'il contrôle.
2. Pendant une installation de paquet, l'attaquant répond à une demande de paquet par une redirection HTTP dont l'URI cible correspond à un autre téléchargement déjà dans la file d'APT.
3. APT donne aux deux téléchargements le même fichier de destination.
4. L'attaquant renvoie une erreur serveur temporaire pour qu'APT réessaie le téléchargement, ce qu'il fait par défaut avec Acquire::Retries 3.
5. APT rouvre la destination existante avec WriteAny et reprend l'écriture au décalage précédent, donc les octets de la nouvelle tentative arrivent dans l'inode qui a été vérifié.
6. Le paquet remplacé est installé par dpkg avec les privilèges root, et ses scripts de maintenance s'exécutent en root.

Aucun code d'exploit public n'existe. Les étapes suivent le mécanisme décrit dans l'avis Debian et le commit de correction, pas une preuve de concept publiée.

Comment se déroule l'attaque ?

La chaîne exige un attaquant sur le chemin, une redirection qui fusionne deux téléchargements et une nouvelle tentative qui rouvre le fichier vérifié sur place.

Que peut faire un attaquant ?

Un échange réussi exécute du code arbitraire en root lorsque la victime installe le paquet remplacé. Les scripts de maintenance du paquet s'exécutent en root, donc l'attaquant hérite de tout ce que root peut faire sur cet hôte.

L'impact exige toutes ces conditions :

• L'attaquant peut modifier le trafic HTTP entre APT et l'archive, ou contrôle un miroir ou un proxy utilisé par la victime.
• L'APT de la victime a un Acquire::Retries non nul, ce qui est la valeur par défaut depuis Debian 12 et Ubuntu 22.04.
• L'attaquant peut faire suivre à APT une redirection qui donne à deux téléchargements la même URI.
• Une installation de paquet a lieu pendant l'attaque, et l'attaquant peut forcer la nouvelle tentative dont la reprise a besoin.

Un attaquant qui peut déjà modifier le trafic de l'archive ne peut servir un paquet malveillant que si le client l'accepte. Les contrôles de signature des métadonnées du dépôt empêchent un paquet forgé de provenir d'un dépôt non signé. Cette faille contourne cette frontière en remplaçant un paquet après la vérification d'APT. Aucune exploitation en conditions réelles n'est connue, et aucune preuve de concept publique n'existe.

Pourquoi le correctif fonctionne-t-il ?

Le correctif ouvre chaque destination de téléchargement avec un indicateur exclusif. Le code ajouté dans methods/http.cc est :

// If we are resuming, we first need to rescue the data we already have
FileFd partial;
if (Req.StartPos > 0 && FileExists(Queue->DestFile))
{
   if (not partial.Open(Queue->DestFile, FileFd::ReadOnly))
      return ERROR_NOT_FROM_SERVER;
}
// Open the file exclusively to avoid injection attacks by links
if (Req.File.Open(Queue->DestFile, FileFd::WriteAny | FileFd::Exclusive) == false)
   return ERROR_NOT_FROM_SERVER;
if (partial.IsOpen())
{
   // The exclusive open unlinked the old file; copy its content
   // into the new one and rewind for hashing.
   if (not CopyFile(partial, Req.File) || not partial.Close() || not Req.File.Seek(0))
      return ERROR_NOT_FROM_SERVER;
}

FileFd::Exclusive refuse d'ouvrir un fichier existant. Dans ce chemin, APT lit d'abord le fichier partiel par un descripteur en lecture seule. Il crée ensuite un nouveau fichier pour le téléchargement.

Un lien matériel ou symbolique à la destination ne reçoit plus l'écriture. L'ancienne entrée de répertoire est supprimée et un nouvel inode est créé. Les octets repris sont copiés dans le nouveau fichier, donc le fichier qu'APT vérifie et celui qu'il installe sont le même nouvel inode.

Le commit applique la même ouverture exclusive à la méthode de correctif rred et à la méthode store. Il ajoute aussi un test d'intégration qui télécharge vers un lien matériel et vers un lien symbolique pointant vers un fichier victime. Le test vérifie que le fichier victime reste inchangé. Le correctif est complet pour les chemins d'écriture modifiés par le commit. Il ne supprime pas le comportement de nouvelle tentative ; il rend l'écriture de reprise sûre.

Comment vérifier si j'ai été compromis ?

Aucun indicateur de compromission n'est publié. Un échange réussi laisse le paquet de l'attaquant installé, et les fichiers et sommes de contrôle enregistrés par dpkg correspondent à ce paquet : rien sur la machine ne paraît incohérent. La piste est un écart avec l'index officiel des paquets, la première des deux vérifications de cette section. Une tentative qui a échoué peut ne laisser aucune trace.

Deux vérifications réduisent la question :

1. Pour chaque paquet installé par APT pendant la fenêtre d'exposition, téléchargez la même version depuis l'archive officielle en HTTPS et comparez ses sommes de contrôle de fichiers avec celles que dpkg a enregistrées à l'installation.

bash v=$(dpkg-query -W -f='${Version}' apt) apt-get download "apt=$v" dpkg-deb -I apt_*.deb md5sums | diff - /var/lib/dpkg/info/apt.md5sums

Exécutez-la avec des sources qui pointent vers l'archive officielle en HTTPS, et répétez-la pour chaque paquet installé pendant cette période. dpkg enregistre les sommes de contrôle des fichiers qu'il a décompressés, pas un hachage du .deb : un paquet substitué apporte donc sa propre liste cohérente.

Toute différence avec le paquet officiel est une piste, car un miroir ou un proxy peut avoir remplacé le fichier. Ce n'est pas une preuve à elle seule, car une reconstruction locale change aussi les sommes de contrôle.

1. Comparez les versions installées avec l'archive de la distribution :

bash apt-cache policy apt

Une version absente de la liste des candidates de l'archive est une piste. Un paquet remplacé peut conserver sa version déclarée, donc des versions identiques n'innocentent pas l'hôte.

Traitez une incohérence inexpliquée de somme de contrôle ou de version sur une machine qui a installé des paquets en HTTP comme une compromission possible. Reconstruisez l'hôte à partir d'une image de confiance et renouvelez les identifiants qu'il détenait.

Chronologie

• 2026-10-12 : le commit de correction « methods: Open target files exclusively » est écrit et validé, et la CVE est réservée le même jour.
• 2026-11-04 : CVE-2026-109518 est publiée à 15:49 UTC. Debian publie DSA-6607-1 et DLA-4880-1, et Ubuntu publie USN-8996-1.
• 2026-11-04 : Ubuntu publie les versions corrigées d'APT pour 26.10, 26.04 LTS, 24.04 LTS et 22.04 LTS dans son archive de sécurité à 14:25 UTC.

FAQ

HTTPS suffit-il à bloquer cette faille ?

Les avis décrivent l'attaque en HTTP et ne précisent pas si les sources HTTPS sont exposées. Utilisez des miroirs HTTPS lorsque c'est possible, mais ne considérez pas HTTPS comme un substitut au paquet APT corrigé. La faille se situe dans la façon dont le fichier est écrit après le téléchargement, pas seulement dans le chiffrement du canal.

J'utilise Debian 11 ou Ubuntu 20.04. Suis-je concerné ?

Pas dans une configuration par défaut. Acquire::Retries n'était pas la valeur par défaut avant Debian 12 et Ubuntu 22.04, et l'attaque exige une nouvelle tentative. Si un script ou un administrateur a activé les nouvelles tentatives, le système est exposé. L'enregistrement CVE donne 2.2.5 comme première version corrigée de la branche 2.2.x, et Ubuntu 20.04 a 2.0.12+esm1 avec Ubuntu Pro.

La faille peut-elle être exploitée sans attaquant sur le chemin ?

Aucun autre vecteur n'est publié. Les avis décrivent un attaquant qui peut manipuler le trafic HTTP, y compris un miroir ou un proxy malveillant. Un attaquant local non privilégié qui peut créer un lien matériel au chemin de téléchargement relève d'un autre modèle de menace, et le test du correctif couvre aussi ce cas.

Existe-t-il un exploit public ou une exploitation en conditions réelles ?

Aucune preuve de concept publique n'est publiée, et aucune exploitation en conditions réelles n'est connue au 5 novembre 2026. CVE-2026-109518 n'est pas au catalogue KEV de la CISA.

Acquire::Retries "0" corrige-t-il complètement la faille ?

Cela supprime la nouvelle tentative dont l'attaque a besoin, et le fil de divulgation la décrit comme une atténuation en attendant la mise à jour. Cela ne change pas l'écriture sur place dans le binaire. Installez le paquet APT corrigé comme correctif permanent.

Pourquoi Ubuntu note-t-il 7,7 High alors que l'impact est une exécution de code en root ?

Le score de base CVSS v4.0 compte les conditions dont l'attaque a besoin, à savoir des conditions d'attaque présentes (la redirection et la nouvelle tentative) et une interaction utilisateur passive (l'installation). Elles font baisser le score à 7,7 High alors que l'impact reste élevé. La priorité d'Ubuntu pour la CVE est High.

Références

• Debian, « DSA-6607-1 apt: security update ». https://www.debian.org/security/2026/dsa-6607 (vérifié le 5 novembre 2026)
• Debian, entrée « CVE-2026-109518 » du suivi de sécurité, avec les paquets corrigés et la référence DLA-4880-1. https://security-tracker.debian.org/tracker/CVE-2026-109518 (vérifié le 5 novembre 2026)
• Debian, « DLA-4880-1 apt: security update ». https://security-tracker.debian.org/tracker/DLA-4880-1 (vérifié le 5 novembre 2026)
• Ubuntu, « USN-8996-1: APT vulnerability ». https://ubuntu.com/security/notices/USN-8996-1 (vérifié le 5 novembre 2026)
• Ubuntu, « CVE-2026-109518 ». https://ubuntu.com/security/CVE-2026-109518 (vérifié le 5 novembre 2026)
• CVE Program, enregistrement « CVE-2026-109518 », CNA Canonical, publié le 4 novembre 2026. https://www.cve.org/CVERecord?id=CVE-2026-109518 (vérifié le 5 novembre 2026)
• Jan Schaumann, « CVE-2026-109518: RCE in apt(1) (DSA 6607-1) », oss-security, 4 novembre 2026. https://www.openwall.com/lists/oss-security/2026/11/04/12 (vérifié le 5 novembre 2026)
• APT, commit de correction « methods: Open target files exclusively ». https://salsa.debian.org/apt-team/apt/-/commit/5af16a8ad0f155233dfb10b7c92ad1903112ef79 (vérifié le 5 novembre 2026)