Faille APT - CVE-2026-109518 - un paquet vérifié peut être remplacé et exécuté en root

La faille APT CVE-2026-109518 peut transformer une installation de paquet en exécution de code avec les droits root sur Debian et Ubuntu. Dévoilée le 4 novembre 2026, elle touche le gestionnaire chargé de télécharger et d’installer les logiciels du système. Les correctifs sont disponibles. Bulletin de sécurité Debian DSA-6607-1.

Le problème est particulièrement sensible : un paquet peut être remplacé après sa vérification. L’opération censée maintenir le serveur devient alors le point d’entrée de l’attaque.

Un paquet contrôlé, puis remplacé avant installation

APT intervient lors des installations et mises à jour réalisées avec apt, apt-get ou d’autres interfaces reposant sur sa bibliothèque. Canonical classe la vulnérabilité en sévérité élevée, avec un score CVSS 4.0 de 7,7. Analyse officielle Ubuntu.

Debian décrit une mauvaise gestion des fichiers lors de la reprise d’un téléchargement HTTP. Une redirection peut amener deux téléchargements distincts à partager la même adresse ; la reprise permet ensuite de modifier un fichier déjà vérifié. Le contrôle a porté sur un contenu qui n’est plus celui finalement installé. Description technique Debian.

Les mainteneurs précisent que le mécanisme implique la réutilisation de liens physiques, plusieurs noms pouvant désigner le même fichier sur disque. Il ne s’agit donc pas de casser la cryptographie des signatures des dépôts, mais de contourner le résultat du contrôle en changeant le fichier ensuite. Annonce de l’équipe APT.

Lors de l’installation, les scripts d’un paquet peuvent s’exécuter en root. Un paquet contrôlé par l’attaquant lui donne alors les mêmes privilèges. Impact détaillé par Canonical.

Quelles conditions rendent l’attaque possible ?

L’attaquant doit pouvoir manipuler le trafic HTTP entre le client APT et le dépôt, ou contrôler un miroir ou un proxy utilisé. L’exploitation combine des redirections et une nouvelle tentative de téléchargement après erreur. Le paramètre Acquire::Retries doit être supérieur à zéro.

Cette nouvelle tentative est activée par défaut à partir de Debian 12 et Ubuntu 22.04 LTS. Une branche plus ancienne peut aussi être concernée si sa configuration ou ses scripts activent ce comportement. Conditions et configuration par défaut dans le suivi Debian.

Le simple fait d’exposer un site web sur Debian ou Ubuntu ne suffit donc pas à reproduire ce scénario : l’attaque passe par l’installation d’un paquet sur le système.

Les versions APT corrigées sur Debian et Ubuntu

Voici les versions corrigées annoncées pour les branches récentes, au 5 novembre 2026 :

Distribution	Version corrigée du paquet apt
Debian 12 Bookworm	2.6.2
Debian 13 Trixie	3.0.4
Ubuntu 22.04 LTS	2.4.15ubuntu0.1
Ubuntu 24.04 LTS	2.8.4ubuntu0.1
Ubuntu 26.04 LTS	3.2.1ubuntu0.1
Ubuntu 26.10	3.3.3ubuntu0.1

Sources : suivi de sécurité Debian et bulletin Ubuntu USN-8996-1.

Des correctifs existent aussi pour d’anciennes versions Ubuntu, via Ubuntu Pro ou son extension Legacy selon la branche. Il faut vérifier la révision distribuée pour son système, plutôt que comparer uniquement le début du numéro de version. Versions et canaux de support Ubuntu.

Mettre à jour APT sans utiliser la reprise vulnérable

Pour inventorier les paquets APT installés :

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

La procédure ciblée de Canonical désactive les nouvelles tentatives pendant la correction :

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

L’option s’applique à cette commande et neutralise la reprise vulnérable. Les contrôles habituels restent actifs. Procédure officielle de Canonical.

Après l’opération, relancez l’inventaire et comparez les versions aux bulletins de votre distribution. Une tâche automatique configurée ne démontre pas que la correction est effectivement installée.

HTTPS protège le trajet, le correctif protège APT

Passer les dépôts en HTTPS, lorsqu’ils le prennent en charge, protège contre la manipulation du trafic en chemin. Cela ne résout pas le cas d’un miroir lui-même malveillant. La mise à jour d’APT reste nécessaire. Mesures de protection et limites décrites par Canonical.

Nous recommandons de vérifier les dépôts réellement utilisés, y compris ceux déclarés dans les fichiers .sources et .list, ainsi que les éventuels proxys de téléchargement.

En production, vérifier chaque environnement qui installe des paquets

Notre recommandation est de traiter cette correction sur un inventaire : serveurs, machines virtuelles, environnements de construction et images de conteneurs utilisant APT. Mettre à jour l’hôte ne met pas à jour les paquets présents dans une image de conteneur. Les images concernées doivent aussi être reconstruites puis redéployées.

La validation doit couvrir la version obtenue et le fonctionnement des services. Notre retour sur une mise à jour Apache sous Ubuntu rappelle pourquoi un déploiement de correctif doit être suivi de contrôles applicatifs.

C’est le rôle d’une infogérance de serveurs Linux : identifier le périmètre, appliquer la correction adaptée et vérifier le résultat. Sur une faille qui touche l’outil de maintenance lui-même, cette chaîne doit être maîtrisée jusqu’au bout.

FAQ - faille APT et CVE-2026-109518

Un serveur Debian ou Ubuntu peut-il être attaqué sans installation de paquet ?

Le scénario décrit nécessite un téléchargement de paquet par APT, des redirections et une nouvelle tentative après erreur, avec Acquire::Retries supérieur à zéro. L’attaquant doit pouvoir manipuler le trafic HTTP ou contrôler un miroir utilisé.

Passer les dépôts APT en HTTPS suffit-il ?

HTTPS protège le trajet, pas contre un miroir malveillant. Il faut installer le correctif APT.