CVE-2026-109518 : Faille APT permet l’exécution de code racine MitM

Une vulnérabilité de gravité élevée dans APT, le système de gestion de paquets utilisé par Debian, Ubuntu et les distributions Linux dérivées, pourrait permettre à un attaquant sur le chemin de remplacer un logiciel vérifié par un logiciel malveillant et d’exécuter du code arbitraire avec des privilèges root. Suivi sous le code CVE-2026-109518, cette faille a un score CVSS 4.0 de 7,7 et affecte la gestion des téléchargements et des réessais HTTP d’APT.

La vulnérabilité est causée par une mauvaise gestion des liens physiques lorsque APT suit les redirections HTTP et réessaye les téléchargements de paquets échoués. Dans les conditions appropriées, deux téléchargements différents peuvent être fusionnés après qu’une redirection les pousse à se résoudre au même URI. Un attaquant capable de manipuler le trafic entre un client APT et un dépôt peut exploiter ce comportement pour remplacer un paquet .deb contrôlé par l’attaquant après que la vérification ait déjà eu lieu.

Étant donné que les paquets Debian peuvent exécuter des scripts d’installation avec des privilèges root, une exploitation réussie peut entraîner un compromis complet du système. Cependant, l’exploitation nécessite plusieurs conditions : la victime doit initier une installation de paquet, APT doit communiquer sur un HTTP manipulable, et l’option Acquire::Retries doit être définie sur une valeur non nulle.

Ubuntu 22.04 LTS et les versions plus récentes sont exposées par défaut car les réessais sont activés. Debian a également activé les réessais par défaut depuis APT 2.3.2, y compris Debian 12. Les anciennes versions peuvent encore être vulnérables lorsque les administrateurs ou les scripts d’automatisation activent manuellement les réessais.

Contactez le service commercial

La vulnérabilité a été découverte par le chercheur en sécurité Max Justicz et divulguée publiquement le 4 novembre 2026. Debian et Ubuntu ont publié des mises à jour de sécurité le même jour. Aucun avis de l’un ou l’autre des vendeurs ne rapporte actuellement d’exploitation de la faille dans des attaques réelles.

Les équipes de sécurité peuvent utiliser la plateforme d’intelligence de détection native de SOC Prime pour opérationnaliser le renseignement sur les menaces et renforcer les défenses contre les attaques de la chaîne d’approvisionnement logicielle, les abus de gestionnaires de paquets, l’exécution de charges utiles malveillantes et les activités post-compromission à travers les environnements SIEM, EDR, XDR et Data Lake.

Détecter CVE-2026-109518 en surveillant les changements suspects dans le trafic du dépôt de paquets, les redirections inattendues ou les échecs de téléchargement de paquets répétés, les installations de paquets anormales, et les nouveaux processus privilégiés survenant immédiatement après l’activité d’APT.

Le contenu de détection peut ne pas être disponible pour chaque CVE. Vérifiez la plateforme SOC Prime pour la couverture actuelle. Si les détections pertinentes ne sont pas encore disponibles, vérifiez de nouveau car le renseignement sur les menaces et le contenu de détection sont continuellement ajoutés.

Analyse du CVE-2026-109518

CVE-2026-109518 affecte les déploiements APT sur Debian, Ubuntu et les distributions Linux dérivées lorsque les fichiers de paquets sont téléchargés via un chemin HTTP manipulé par un attaquant et que la fonctionnalité de réessai est activée. Ubuntu classifie la vulnérabilité comme Élevée avec un score CVSS 4.0 de 7,7 et le vecteur CVSS:4.0/AV/AC/AT/PR/UI/VC/VI/VA/SC/SI/SA.

APT est responsable du téléchargement, de la vérification et de l’installation des paquets sur les systèmes Linux basés sur Debian. L’authenticité des paquets repose normalement sur les mécanismes de signature des dépôts Debian et Ubuntu conçus pour garantir que les paquets livrés par les miroirs ne peuvent pas être modifiés silencieusement par un intermédiaire non fiable.

CVE-2026-109518 casse une partie importante de ce modèle de confiance sous des conditions de téléchargement spécifiques.

La vulnérabilité se produit lorsque APT gère les redirections HTTP et les réessais. Selon un avis de Debian, APT peut fusionner deux téléchargements de paquets séparés lorsqu’une redirection les amène à partager le même URI. Lorsqu’un téléchargement doit ensuite être repris, une mauvaise gestion des liens physiques réutilisés peut permettre d’écraser le contenu associé à un paquet déjà vérifié.

Un attaquant doit d’abord avoir la capacité de manipuler le trafic HTTP entre la victime et l’archive de paquets. Les positions potentielles incluent un intermédiaire réseau malveillant ou compromis, un proxy, un réseau Wi-Fi ou un miroir de paquets. Ubuntu inclut explicitement les miroirs et proxys malveillants dans son modèle de menace.

L’attaquant peut alors utiliser les redirections avec des erreurs HTTP transitoires pour forcer APT dans son chemin de réessai. Lorsque APT réessaye le téléchargement du paquet, la faille dans la gestion des liens physiques peut amener les données contrôlées par l’attaquant à remplacer le contenu associé à un paquet qui a déjà passé la vérification.

Cela permet au paquet malveillant de contourner la protection normalement fournie par les signatures de dépôt.

L’impact devient particulièrement grave car les paquets .deb peuvent contenir des scripts de maintenance exécutés pendant l’installation. Ces scripts s’exécutent avec des privilèges root lors de l’installation des paquets, ce qui signifie qu’un attaquant qui réussit à substituer un paquet peut exécuter des commandes avec des privilèges système complets.

La vulnérabilité ne signifie pas que chaque hôte Debian ou Ubuntu peut être compromis à distance à tout moment. L’attaque nécessite que le système victime exécute une installation ou une mise à jour de paquet pendant que l’attaquant peut interférer avec le chemin réseau.

Une autre condition préalable importante est Acquire::Retries.

APT utilise cette option pour déterminer si les téléchargements échoués doivent être automatiquement réessayés. Le comportement vulnérable nécessite une valeur supérieure à zéro. Les développeurs APT de Debian déclarent que les réessais ont été activés par défaut depuis APT 2.3.2, tandis qu’Ubuntu confirme que les versions 22.04 LTS et plus récentes d’Ubuntu utilisent une valeur par défaut non nulle.

Les systèmes plus anciens ne sont donc pas nécessairement sûrs. Bien que les versions antérieures à Ubuntu 20.04 LTS ne permettent pas les réessais par défaut, des configurations personnalisées, une automatisation de déploiement ou des scripts d’administrateur peuvent définir Acquire::Retries manuellement et rendre ces systèmes exploitables.

La vulnérabilité existe dans le backend HTTP d’APT et s’applique donc à tous les frontends basés sur APT, y compris apt, apt-get, aptitude, et les applications graphiques Ubuntu qui utilisent finalement la même infrastructure de gestion de paquets. Les paquets Snap ne sont pas affectés car ils utilisent un mécanisme de distribution différent.

HTTPS modifie également considérablement la surface d’attaque. Ubuntu affirme que TLS protège contre cette vulnérabilité car l’attaquant doit être capable de modifier le trafic HTTP en transit. Les sources de paquets accessibles exclusivement via HTTPS correctement validé sont donc protégées contre la méthode d’attaque documentée sur le chemin. Les mécanismes de transport FTP et non apparentés ne sont pas affectés par ce problème spécifique.

Le contexte de PoC de CVE-2026-109518 doit être interprété avec prudence. Les avis officiels de Debian et Ubuntu ne contiennent pas de lien vers un exploit public démontrant une compromission totale des droits root, et ils ne rapportent pas d’exploitation malveillante dans la nature. Les informations techniques publiées par les développeurs d’APT expliquent néanmoins suffisamment le comportement des redirections, des réessais et des liens physiques pour que les défenseurs comprennent les exigences de l’attaque.

La faiblesse est associée à une mauvaise gestion des liens physiques et à une condition de vérification/temps d’utilisation. L’enregistrement CVE la lie à CWE-62, Hard Link UNIX, et CWE-367, Time-of-check Time-of-use Race Condition.

Les développeurs d’APT ont publié des versions corrigées sur plusieurs branches maintenues :

Debian 13 “Trixie” a reçu APT 3.0.4, tandis que Debian 12 “Bookworm” a reçu la version 2.6.2.

Ubuntu a publié les paquets corrigés suivants :

Les mises à jour pour les anciennes versions d’Ubuntu nécessitent la couverture Ubuntu Pro ou Extended Security Maintenance applicable.

Pour la détection de CVE-2026-109518, les équipes de sécurité devraient corréler l’activité de gestion des paquets avec la télémétrie réseau et endpoint. Des redirections HTTP répétées, des échecs de téléchargement transitoires immédiatement suivis d’une récupération de paquet réussie, des destinations de dépôt inattendues, ou des installations de paquets à partir de chemins réseau inhabituels peuvent fournir des pivots d’investigation utiles.

La surveillance des endpoints devrait aussi identifier des processus enfants inhabituels générés pendant ou immédiatement après l’exécution d’APT ou dpkg. Étant donné qu’une exploitation réussie entraîne l’installation d’un paquet contrôlé par un attaquant en tant que root, l’exécution suspecte de shell, les nouveaux services, les fichiers système modifiés, les mécanismes de persistance, la création d’utilisateurs, l’accès aux informations d’identification ou les connexions sortantes inattendues suivant l’installation de paquets devraient être traités comme des indicateurs de haute priorité.

Les journaux APT et dpkg peuvent fournir des contextes supplémentaires. Les défenseurs devraient examiner /var/log/apt/, /var/log/dpkg.log, les enregistrements du journal système, la télémétrie des proxys, les journaux DNS et les données de sécurité réseau autour des opérations de paquets suspectes. Comparer les versions et checksums des paquets installés avec les dépôts de distribution de confiance peut aider à identifier des modifications inattendues.

À ce jour, les avis des fournisseurs ne fournissent pas d’infrastructure d’attaquant, de hachages de logiciels malveillants ou d’IOCs spécifiques à une campagne pour CVE-2026-109518 parce que Debian et Ubuntu n’ont pas signalé d’exploitation malveillante active. La surveillance comportementale est donc plus précieuse que la recherche d’une liste IOC statique.

Atténuation de CVE-2026-109518

Le principal remède consiste à installer le paquet APT mis à jour fourni par Debian, Ubuntu ou la distribution dérivée pertinente. Les administrateurs ne doivent pas se reposer uniquement sur les contrôles réseau car l’implémentation corrigée d’APT empêche le contournement de la vérification des paquets à sa source.

Ubuntu recommande de mettre à jour tous les paquets installés tout en désactivant explicitement les réessais pendant le processus de mise à niveau :

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

Les organisations qui ne peuvent pas effectuer une mise à jour complète du système peuvent cibler APT lui-même :

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

Définir les réessais à zéro pendant cette opération empêche le chemin de réessai vulnérable d’être utilisé pendant que la mise à jour de sécurité elle-même est téléchargée et installée.

Les équipes de sécurité doivent suivre les étapes suivantes :

1. Inventorier les systèmes Debian, Ubuntu et Linux dérivés utilisant APT.
2. Identifier la version installée d’APT et la comparer avec la version corrigée par le fournisseur.
3. Prioriser les systèmes connectés à Internet et les environnements utilisant des miroirs de paquets non fiables, tiers ou communautaires.
4. Appliquer la mise à jour de sécurité du fournisseur avec Acquire::Retries=0.
5. Confirmer que le paquet APT corrigé est installé.
6. Passer en revue /etc/apt/sources.list et les fichiers sous /etc/apt/sources.list.d/ pour des dépôts HTTP inattendus.
7. Déplacer les sources de paquets de HTTP à HTTPS lorsque cela est pris en charge.
8. Examiner l’infrastructure de proxy et de miroir de paquets pour tout signe de compromission ou de modification non autorisée.
9. Enquêter sur les installations de paquets inattendues qui ont eu lieu avant le déploiement du correctif.

Ubuntu confirme que changer les dépôts de paquets vers HTTPS offre une protection contre l’attaque documentée car l’exploitation nécessite une modification du trafic HTTP. Les administrateurs doivent d’abord vérifier que leurs miroirs de dépôt choisis prennent en charge TLS puis exécuter sudo apt update pour s’assurer que la configuration fonctionne sans erreurs.

Utiliser HTTPS doit être considéré comme une défense en profondeur plutôt qu’un substitut à la mise à jour d’APT. Les systèmes peuvent plus tard utiliser un autre dépôt, un proxy, un workflow d’automatisation ou un point de terminaison HTTP, donc l’installation du paquet corrigé reste nécessaire.

Définir temporairement Acquire::Retries à zéro fournit une autre solution efficace contre la condition d’exploitation documentée. Étant donné que la faille dépend du fait qu’APT réessaye un téléchargement échoué, désactiver les réessais empêche le chemin de code vulnérable d’être atteint. Ce réglage peut réduire la fiabilité du téléchargement de paquets, cependant, et devrait être principalement utilisé tout en appliquant la mise à jour de sécurité réelle.

Les organisations utilisant des mises à jour automatiques doivent vérifier le déploiement du correctif plutôt que de supposer que chaque machine a déjà été corrigée. Ubuntu note que les mises à jour automatiques sont activées par défaut depuis Ubuntu 16.04 LTS et appliquent normalement les mises à jour de sécurité dans les 24 heures, mais la gestion de flotte, les restrictions réseau, les configurations de dépôts personnalisées ou les services désactivés peuvent empêcher une installation réussie.

Si une compromission est suspectée, les administrateurs doivent préserver APT, dpkg, proxy, réseau et les journaux système avant la remédiation. Examiner les paquets installés durant la fenêtre d’exposition suspectée, valider la provenance des paquets, inspecter les scripts des mainteneurs, et enquêter sur tout processus de niveau root ou persistance établi immédiatement après.

Parce qu’un paquet malveillant peut exécuter des commandes arbitraires en tant que root, une exploitation confirmée doit être traitée comme une compromission totale du système. Reconstruire l’hôte affecté à partir de médias de confiance peut être plus fiable que tenter de supprimer des artefacts individuels, surtout lorsque l’attaquant pourrait avoir modifié des binaires système, des services, la configuration d’authentification, ou des composants au niveau du noyau.