L’équipe CVE du noyau Linux a attribué l’identifiant CVE-2026-64564 le 4 août 2026 à un use-after-free logé dans le code SCTP du noyau. Deux jours plus tard, le Tencent Zhuque Lab publiait son analyse technique complète sous le nom SCTPhantom. Le comportement fautif traîne dans le noyau depuis décembre 2007. Environ 18 ans.
Le score CVSS v4.0 est de 8.5 (High), avec le vecteur CVSS:4.0/AV:L/AC:L/AT:N/PR:L/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N, et la faille donne le root sur l’hôte à un utilisateur local non privilégié. Y compris depuis l’intérieur d’un conteneur Docker.
Une précision avant tout le reste, parce que ce type de vulnérabilité Linux est régulièrement mal raconté : SCTPhantom ne s’exploite pas à distance. Le vecteur est local (AV:L). Il faut déjà exécuter du code sur la machine, ou dans un conteneur qui y tourne. Personne ne traversera votre box pour atteindre votre serveur avec ça.
Ce que fait le bug
SCTP, c’est le Stream Control Transmission Protocol, défini par la RFC 4960. La faille se trouve dans son extension de reconfiguration dynamique d’adresses, ASCONF (RFC 5061), dans le fichier net/sctp/sm_make_chunk.c.
Quand le noyau traite un chunk ASCONF, sctp_process_asconf() met le transport courant en cache dans asconf->transport. Une séquence forgée et ordonnée [Address Parameter L] [DEL-IP L] [DEL-IP 0.0.0.0], où L n’est pas l’adresse source du paquet, franchit sans encombre le contrôle D8, qui ne protège que l’adresse source. Le premier DEL-IP libère le transport. La branche wildcard juste derrière réutilise ce pointeur devenu invalide, et un pointeur libéré se retrouve dans asoc->peer.primary_path et active_path.
Le correctif amont refuse un DEL-IP qui vise le transport dont l’ASCONF est en cours de traitement. Il est arrivé en mainline avec le commit 9b2854f86f0b. Le comportement vulnérable, lui, remonte au commit 42e30bf3463c, livré avec Linux 2.6.25 en décembre 2007.
Pourquoi ça concerne un homelab
Le Tencent Zhuque Lab (l’équipe sécurité de TencentOS) a repéré la faille avec un pipeline multi-agents maison baptisé Corvus AI, puis a monté une chaîne d’exploitation complète autour, jusqu’au root global et à l’évasion de conteneur. Le détail est dans leur publication.
Le point qui doit vous intéresser si vous faites tourner des conteneurs est ailleurs. L’évasion de conteneur a été validée avec le profil seccomp Docker par défaut actif. Sans CAP_NET_ADMIN. Sans CAP_SYS_ADMIN. Sans toucher non plus aux sysctls net.sctp.addip_enable et net.sctp.addip_noauth_enable, parce que les options par socket SCTP_ASCONF_SUPPORTED et SCTP_AUTH_SUPPORTED ont suffi. Six tentatives sur huit ont atteint le root de l’hôte. Les deux qui ont échoué se sont arrêtées proprement, sans panique du noyau.
Le root a été obtenu sur Linux 7.2-rc2 (un noyau de recherche), OpenCloudOS 6.6.119, Debian 13 (6.12.95+deb13-amd64), Rocky Linux 9 et RHEL 9 avec le noyau vendeur 5.14 et le module SCTP chargé, ainsi que sur Ubuntu 24.04 (6.8.0-134-generic).
Mettez cette liste en face d’un homelab ordinaire. Un hôte Docker, un nœud Proxmox, une machine TrueNAS SCALE, une install OpenMediaVault, un simple serveur Debian ou Ubuntu : tous partagent un seul noyau avec tout ce qui tourne dessus. Que vous pilotiez vos conteneurs en ligne de commande ou depuis un tableau de bord comme Portainer, la frontière d’isolation reste ce même noyau. C’est précisément ce qu’un bug du noyau ignore. Un conteneur compromis, ou un compte local sans privilèges, et c’est plié.
Les noyaux corrigés
Les premières versions saines sont les suivantes :
- 6.6.148
- 6.12.101
- 6.18.42
- 7.1.6
- mainline 7.2-rc5
Une mise en garde qui vaut la peine d’être répétée, parce qu’elle est ratée à chaque CVE noyau : les distributions rétroportent les correctifs en gardant un ancien numéro de version. Le numéro seul ne prouve rien, ni dans un sens ni dans l’autre. Regardez plutôt l’avis de sécurité de votre distribution, ou le paquet source. Debian 13 a déjà publié une mise à jour du noyau qui corrige SCTPhantom.
Ce qu’il y a à faire
Mettre à jour le noyau, puis redémarrer. C’est le correctif. Sur la plupart des distributions, le paquet corrigé est déjà disponible ou arrive sous peu.
Si le redémarrage doit attendre, il existe un palliatif correct. SCTP est fourni en module chargeable sur la plupart des distributions, et à peu près aucun homelab ne s’en sert. Pour l’empêcher de se charger automatiquement, déposez un fichier dans /etc/modprobe.d/ contenant install sctp /bin/true.
Deux réserves. Vérifiez lsmod d’abord : le blacklist ne fait rien contre un module déjà chargé en mémoire. Et donc le redémarrage finira par arriver de toute façon.
Chronologie
- 12 juillet 2026 : découverte et divulgation privée
- 24 juillet 2026 : correctif fusionné dans l’arbre networking
- 27 juillet 2026 : évasion de conteneur validée
- 4 août 2026 : annonce officielle du CVE par l’équipe CVE du noyau Linux
- 6 août 2026 : publication de l’analyse technique par le Tencent Zhuque Lab, et messages sur oss-security
Mise en perspective
SCTPhantom est un vrai problème, mais pas une raison de tout débrancher ce soir. Il n’y a aucune surface d’attaque distante. Le risque se concentre sur les homelabs qui font tourner des images de conteneurs qu’ils n’ont pas construites, ou qui ouvrent des comptes shell à d’autres personnes que le propriétaire. Si ça ressemble à votre installation, c’est un sujet pour la prochaine fenêtre de maintenance, pas pour le prochain trimestre. Le problème n’a pas la même forme que le contournement d’authentification Docker de Gitea, qui était exploité depuis l’extérieur en quelques jours.
Sources : l’analyse technique du Tencent Zhuque Lab et la fiche NVD de CVE-2026-64564.