Ce que SCTPhantom casse réellement

CVE-2026-64564 - surnommée SCTPhantom par certains des chercheurs qui l'ont couverte - est une vulnérabilité use-after-free au sein de l'implémentation SCTP du noyau Linux, le Stream Control Transmission Protocol utilisé surtout dans la signalisation télécom, certains systèmes de messagerie financière et quelques piles réseau de conteneurs et de clusters. La faille se situe précisément dans ASCONF, le code qui gère la Reconfiguration Dynamique d'Adresses, et qui permet à une association SCTP active d'ajouter ou de retirer des adresses IP sans rompre la connexion. Le CVE a été officiellement annoncé le 4 août 2026, après un processus de divulgation privée entamé dès le 12 juillet 2026.

La cause profonde est un décalage d'identité: lorsque le noyau traite une demande DEL-IP visant à retirer une adresse d'une association, il valide cette demande à partir de l'adresse source du paquet entrant, tandis qu'un pointeur mis en cache, distinct, continue de se référer à l'adresse indiquée dans le paramètre de la demande elle-même. Un attaquant qui construit une séquence de chunks ASCONF délibérément ordonnée peut exploiter cet écart entre les deux vérifications pour libérer une zone de mémoire noyau alors qu'un pointeur actif y pointe encore - la définition même d'une use-after-free, et l'un des moyens les plus fiables de transformer un bug noyau en exécution de code réelle.

Dix-huit ans, c'est le titre, pas la leçon

Le code responsable remonte à Linux 2.6.25, publié en décembre 2007, ce qui situe le bug à environ 18 ans d'âge au moment où le Zhuque Lab de Tencent l'a découvert. Les chercheurs attribuent la découverte à Corvus AI, une chaîne autonome multi-agents de recherche de vulnérabilités que l'équipe exploite en interne, qui a signalé le chemin de code ASCONF comme méritant un examen manuel plus approfondi. Ce détail compte presque autant que le bug lui-même: il ne s'agit pas d'une zone du noyau réputée à risque enfin auditée, mais d'un recoin réellement obscur que quasiment personne n'avait examiné en profondeur depuis près de deux décennies.

Les correctifs stables sont arrivés le 3 août 2026 dans les branches noyau 6.6.148, 6.12.101, 6.18.42 et 7.1.6, et les mainteneurs des distributions ont déjà commencé à les intégrer à leurs propres arbres de paquets. C'est la partie de l'histoire que chaque média relaie, et c'est aussi la partie qui compte le moins pour la plupart des lecteurs. Un écart de 18 ans entre la publication du bug et sa découverte prouve qu'une politique consistant à attendre le correctif a déjà échoué en silence pendant dix-huit ans sur ce même chemin de code - rien ne permet de supposer que le prochain recoin inexploré du noyau sera trouvé plus vite, d'où l'intérêt de réduire ce qui est réellement atteignable sur une machine donnée, indépendamment de la date d'un correctif en particulier.

Accès root et évasion de conteneurs, démontrés

Le Zhuque Lab de Tencent a démontré l'exploit de bout en bout, pas seulement un plantage. Sur des systèmes sous Debian 13, Ubuntu 24.04, Rocky Linux 9, RHEL 9 et OpenCloudOS, l'équipe a transformé la use-after-free en une élévation de privilèges complète vers root depuis un compte local non privilégié, puis a utilisé la même technique pour s'échapper d'un conteneur vers l'hôte dans six tentatives sur huit, sans avoir besoin de CAP_NET_ADMIN ni de CAP_SYS_ADMIN, les capacités élevées que la plupart des guides de durcissement de conteneurs présupposent comme premier obstacle pour un attaquant.

La chaîne d'exploitation a contourné l'address space layout randomization du noyau, enchaîné une seconde use-after-free à l'aide de clés d'authentification SCTP contrôlées par l'attaquant, et construit un graphe d'objets noyau falsifié pour atteindre root, le tout sans shellcode ni chaîne de programmation orientée retour, les techniques que la plupart des mitigations d'exploits noyau sont conçues pour intercepter. Les tests ont couvert des versions noyau allant de la 5.14 jusqu'à la release candidate 7.2, et le correctif upstream est arrivé sous forme du commit 9b2854f86f0b avant d'être rétroporté vers les quatre branches stables citées plus haut.

Le correctif d'une ligne que la plupart des équipes sautent

Le correctif est réel et mérite d'être appliqué, mais il traite un symptôme. Quasiment aucune des organisations qui font tourner ces cinq distributions n'a choisi d'activer SCTP - il est compilé par défaut directement dans le noyau principal, et la plupart des opérateurs ignorent qu'il est même présent, sans parler du fait qu'un processus local peut l'atteindre. C'est la véritable leçon enfouie dans le propre fil de divulgation oss-security des chercheurs: un contributeur du fil a fait remarquer que les systèmes de la famille RHEL laissent SCTP désactivé par défaut, livré comme paquet séparé kernel-modules-extra dont le chargement automatique est mis en liste noire, tandis que les noyaux des familles Debian et Ubuntu intègrent SCTP en dur et le laissent se charger dès qu'un processus quelconque le demande. Deux systèmes peuvent porter le même CVE et se retrouver face à un risque réel très différent, et cette différence n'a rien à voir avec le correctif installé.

L'action qui mérite d'être menée cette semaine n'est pas d'attendre la mise à jour de la distribution, c'est de vérifier si SCTP sert à quoi que ce soit d'utile sur une flotte donnée. La commande lsmod | grep sctp montre si le module est actuellement chargé; vérifier /etc/modprobe.d/ à la recherche d'une entrée de liste noire existante montre si le chargement automatique est déjà bloqué. Là où rien ne dépend légitimement de SCTP - et sur la plupart des serveurs à usage général, rien n'en dépend - mettre le module en liste noire ferme la porte indépendamment de la version noyau qui finira par arriver, une habitude qui rejoint ce que l'ANSSI recommande déjà en France pour tout module noyau inutilisé, et pas seulement pour celui-ci.

À lire ensuite: Votre MSP a une seconde faille de contournement  |  L'appel qui contourne le MFA de votre entreprise