SCTPhantom, la faille SCTP de 18 ans qui offre un root complet sur le noyau Linux et brise l’isolation des conteneurs
Une vulnérabilité use-after-free dans le protocole SCTP du noyau Linux, vieille de 18 ans et baptisée SCTPhantom, permet à un attaquant local d’obtenir les privilèges root et de s’évader d’un conteneur. Le correctif est disponible depuis le 4 août 2026 — mettez à jour vos noyaux sans délai.
Le 4 août 2026, l’équipe TencentOS Security a divulgué CVE-2026-64564, une vulnérabilité du noyau Linux baptisée SCTPhantom. Le code vulnérable a été introduit avec le noyau Linux 2.6.25 en décembre 2007 — il aura fallu près de 18 ans pour le découvrir. La faille permet une escalade de privilèges locale jusqu’au root et, plus grave encore, une évasion de conteneur vers le système hôte. Validée sur Ubuntu 24.04, Debian 13, Rocky Linux 9 et des noyaux allant de 5.14 jusqu’au 7.2-rc, elle obtient un CVSS 4.0 de 8,5.
Le responsable : le protocole SCTP (Stream Control Transmission Protocol), un cousin méconnu de TCP conçu pour la signalisation télécom, que presque personne n’utilise — mais que presque tout le monde compile en dur dans le noyau.
Un bug d’identité dans ASCONF
Le défaut se niche dans la fonction Dynamic Address Reconfiguration de SCTP, définie par la RFC 5061. Cette extension permet à une association SCTP d’ajouter, supprimer ou reconfigurer des adresses réseau à chaud via des chunks ASCONF. La logique de suppression d’adresse (DEL-IP) compare l’adresse source du paquet avec un pointeur de transport (path) mis en cache — mais les deux proviennent de chemins de code différents qui peuvent diverger.
Un attaquant local peut forger une séquence ASCONF ordonnée : il spécifie une adresse, demande sa suppression, puis envoie une suppression générique (wildcard). Le noyau supprime le transport correspondant, mais un pointeur périmé persiste dans les champs active path et primary path de l’association. Une opération socket ultérieure déréférence cette mémoire libérée — le use-after-free est enclenché.
Les chercheurs de TencentOS, armés de leur système autonome de recherche de vulnérabilités Corvus AI, ont transformé ce bug mémoire brut en chaîne d’exploitation complète. Leur exploit récupère la mémoire libérée via un packet socket ring buffer, ce qui fait fuiter une adresse noyau. Cette fuite permet une lecture contrôlée de quatre octets répétable, utilisée pour vaincre le KASLR en inspectant la table des descripteurs d’interruption (IDT).
Un second use-after-free est alors déclenché avec des données de clé d’authentification SCTP contrôlées par l’attaquant, construisant un graphe d’objets noyau factice qui appelle commit_creds — le tout sans shellcode ni chaîne ROP traditionnelle.
L’évasion de conteneur, le vrai danger
La démonstration la plus préoccupante concerne l’évasion de conteneur. En utilisant des options SCTP par socket plutôt que des sysctls globaux, l’exploit évite d’avoir besoin de capacités élevées. Il a réussi à briser l’isolation de conteneurs exécutant des profils seccomp par défaut dans six tentatives sur huit, déclenchant finalement un processus usermode-helper dans l’espace de noms initial de l’hôte.
Pour une plateforme Kubernetes où des locataires partagent un même nœud, cela signifie qu’un conteneur compromis permet de rebondir sur tous les autres workloads du nœud, puis sur l’hôte lui-même.
Le périmètre concerné est large parce que SCTP est activé par défaut dans la quasi-totalité des noyaux de distribution. La bonne nouvelle : le correctif a été fusionné dans le noyau upstream avec le commit 9b2854f86f0b et rétroporté vers les branches stables 6.6.148, 6.12.101, 6.18.42 et 7.1.6.
Plan d’action immédiat
| Contexte | Action prioritaire |
|---|---|
| Noyau < 6.6.148 | Mise à jour immédiate — le bug est exploitable sans capacités spéciales |
| Noyau 6.12.x | Passer à ≥ 6.12.101 |
| Noyau 7.x | Passer à ≥ 7.1.6 |
| Nœuds Kubernetes multi-tenant | Appliquer le correctif + vérifier les profils seccomp |
| Serveurs bare-metal mutualisés | Priorité critique — un utilisateur local = root |
Si vous ne pouvez pas mettre à jour immédiatement, désactivez le module sctp (modprobe -r sctp puis blacklistez-le dans /etc/modprobe.d/) si votre charge applicative le permet. Dans un cluster Kubernetes, appliquez un PodSecurityPolicy ou un profil seccomp qui bloque les appels système SCTP (socket(AF_INET, SOCK_STREAM, IPPROTO_SCTP)).
SCTPhantom nous rappelle une vérité inconfortable : le code réseau du noyau Linux est un musée vivant. Chaque protocole qu’on laisse compilé « au cas où » est une surface d’attaque qui dort — parfois pendant deux décennies. Le minimalisme de configuration n’est pas un luxe esthétique. C’est une politique de sécurité.