Une évasion de conteneur vers le compte root de l’hôte vient d’être documentée dans le noyau Linux : la faille CVE-2026-64564, surnommée SCTPhantom, dort dans le code SCTP depuis 2008. Pour une PME-ETI qui fait tourner Docker, Kubernetes ou du CI/CD conteneurisé, c’est la frontière d’isolation la plus fondamentale qui tombe : un attaquant qui obtient un shell dans un conteneur peut devenir root sur la machine physique, et donc sur tous les autres conteneurs qu’elle héberge.
Évasion de conteneur : ce que change CVE-2026-64564
Le défaut se situe dans l’implémentation du protocole SCTP (Stream Control Transmission Protocol) du noyau Linux, un composant historiquement utilisé par la téléphonie sur IP et les réseaux opérateurs, mais compilé par défaut dans la quasi-totalité des distributions serveur. Le code vulnérable remonte à 2008 : dix-huit ans de branches maintenues, de noyaux LTS et d’images de base héritent donc du problème.
Les points à retenir :
- Vecteur local : l’attaquant doit déjà disposer d’une exécution de code dans un conteneur — typiquement après l’exploitation d’une application web ou d’une dépendance piégée.
- Impact maximal : élévation vers root sur l’hôte, ce qui annule l’isolation namespaces/cgroups et expose les secrets montés dans les conteneurs voisins.
- Exploitabilité démontrée : le PoC SCTPhantom publié par les chercheurs a réussi sur 6 tentatives sur 8, un taux de fiabilité largement suffisant pour un usage opérationnel.
- Surface large : le module
sctpest chargeable à la demande sur la plupart des systèmes, même quand aucun service ne l’utilise.
Pourquoi le risque est plus élevé qu’il n’y paraît
Beaucoup d’équipes considèrent une faille « locale » comme secondaire. C’est une erreur d’appréciation dans une architecture conteneurisée : le conteneur est le point d’entrée local. Chaque application exposée sur Internet et empaquetée en image constitue un tremplin potentiel. Combinée à une simple RCE applicative, cette évasion de conteneur transforme un incident circonscrit en compromission complète de l’hyperviseur applicatif. Le même raisonnement s’appliquait déjà aux évasions de VM côté KVM.
Contenir l’évasion de conteneur : les mesures immédiates
Trois actions à mener dans les 48 heures, par ordre de rapidité de mise en œuvre.
1. Neutraliser le module SCTP
Si vos serveurs n’utilisent pas SCTP — c’est le cas de l’immense majorité des parcs PME-ETI — le blocage du module supprime la surface d’attaque sans attendre le correctif :
- Vérifier l’usage réel :
lsmod | grep sctppuisss -a | grep -i sctp. - Interdire le chargement automatique via un fichier dans
/etc/modprobe.d/contenantinstall sctp /bin/true. - Régénérer l’initramfs et redémarrer pour rendre le blocage persistant.
2. Appliquer les correctifs noyau
Les distributions ont commencé à publier des noyaux corrigés. La difficulté n’est pas le téléchargement du paquet mais le redémarrage effectif : un noyau installé et non relancé ne protège de rien. Suivez la version réellement en cours d’exécution (uname -r) et non la version installée, et industrialisez la boucle comme décrit dans notre article sur la réduction de la fenêtre de patch.
3. Durcir l’exécution des conteneurs
Une évasion de conteneur exploite presque toujours des privilèges excessifs accordés par défaut. Réduisez-les :
- Bannir
--privilegedet les montages de/var/run/docker.sockdans les charges applicatives. - Supprimer les capabilities inutiles avec
--cap-drop=ALL, puis rajouter uniquement le strict nécessaire. - Activer les profils seccomp et AppArmor/SELinux : un filtre seccomp restrictif bloque les appels système exotiques utilisés par ce type de PoC.
- Exécuter les conteneurs en utilisateur non-root et activer les user namespaces.
- Isoler les charges à risque sur des hôtes dédiés, ou passer à un runtime à isolation renforcée (gVisor, Kata Containers).
Détecter une tentative d’évasion de conteneur
Le patch ferme la porte, la détection vous dit si quelqu’un a essayé. Sur un SOC piloté par l’IA, trois signaux méritent une règle dédiée :
- Chargement inattendu du module
sctpsur un hôte de production. - Création de sockets SCTP par un processus applicatif conteneurisé.
- Apparition d’un processus root sur l’hôte dont le parent appartient à un cgroup de conteneur — signature quasi certaine d’une évasion réussie.
Ces trois règles se déploient en quelques minutes sur un agent de télémétrie standard et transforment une faille silencieuse en alerte exploitable.
Ce qu’il faut retenir
CVE-2026-64564 rappelle une constante de 2026 : la dette technique du noyau reste le maillon faible des architectures modernes. Une évasion de conteneur ne se prévient pas avec une seule mesure, mais avec une chaîne — désactivation du module inutile, patch noyau réellement redémarré, privilèges minimaux, et détection des franchissements de frontière. Les PME-ETI qui appliquent ces quatre couches transforment une vulnérabilité critique en simple ligne de rapport.