> ## Documentation Index > Fetch the complete documentation index at: https://blog.onetsolutions.net/llms.txt > Use this file to discover all available pages before exploring further. # CVE-2026-98432 : faille TCP du noyau Linux exploitable à distance > Use-after-free dans la pile TCP IPv4 du noyau Linux, exploitable à distance sans authentification. Exposition, noyaux corrigés par distribution, mitigation. *Publié le 14 novembre 2026* > [!WARNING] > > **CVE-2026-98432 — noyau Linux, établissement des connexions TCP IPv4.** La faille est notée 9.8 par l'équipe sécurité du noyau. Elle est exploitable à distance, sans authentification, sur tout serveur qui accepte des connexions TCP en IPv4. Installez le noyau corrigé de votre distribution et redémarrez dès aujourd'hui. ## Le problème en deux phrases Pendant l'établissement d'une connexion TCP, le noyau transmet les options IP de la demande de connexion au socket créé, sans les copier, puis les libère sans attendre que les autres processeurs aient fini de les lire. Un SYN retransmis, traité au même moment sur un autre processeur, construit alors son SYN-ACK à partir d'une mémoire déjà libérée : c'est un use-after-free dans `ip_options_build()`. Un second chemin mène au même bug : la migration des demandes de connexion (`net.ipv4.tcp_migrate_req=1` ou un programme BPF `BPF_SK_REUSEPORT_SELECT_OR_MIGRATE`). Versions touchées : * **tous les noyaux Linux depuis la 4.4** ; * corrigés en amont dans **7.3-rc7**, et dans les branches stables **5.10.272, 5.15.223, 6.1.190, 6.6.159, 6.12.113, 6.18.56 et 7.2.10**. Le score de 9.8 vient de l'équipe CVE du noyau et figure dans la fiche NVD. Red Hat retient le même score et classe la faille critique. Ubuntu lui donne la priorité critique. > [!NOTE] > > Anthropic a décrit un exploit écrit par Claude, un modèle de recherche interne non publié : exécution de code à distance en root, sans clic, sur un serveur qui expose un listener Multipath TCP (MPTCP). La publication décrit l'exploit sans en fournir le code. La faille ne figure pas au catalogue KEV de la CISA (version du 13 novembre 2026). ## Évaluer son exposition La question à se poser : **votre serveur accepte-t-il des connexions TCP en IPv4 ?** C'est le cas de presque tous les serveurs : SSH, web, mail, base de données. MPTCP n'est pas une condition de la faille. L'exploit publié s'en sert, mais Red Hat rappelle que le bug est dans le TCP IPv4 ordinaire : RHEL, qui désactive MPTCP par défaut, reste vulnérable. | Profil | Exposition | Action | | - | - | - | | Serveur qui accepte du TCP IPv4 depuis Internet (SSH, web, mail) | **Critique** | Noyau corrigé et redémarrage aujourd'hui ; règle nftables en attendant | | Serveur avec un listener MPTCP (programmes Go 1.24 et ultérieurs, par défaut) | **Critique**, configuration de l'exploit publié | Même action, sans délai | | Serveur joignable uniquement depuis un réseau interne | Élevée | Mettre à jour rapidement | | Nœud Kubernetes ou hôte de conteneurs | **Critique** | Mettre à jour le noyau de chaque nœud ; la règle nftables ne filtre pas le trafic entre pods | | RHEL 6 et 7 | Non affecté selon Red Hat | Aucune action | Pour voir le noyau en cours d'exécution : ```bash theme={null} # Toutes distributions : version du noyau chargé uname -r # Debian : la version du paquet figure dans uname -v uname -v ``` > [!NOTE] > > Désactiver MPTCP (`sysctl -w net.mptcp.enabled=0`) ne protège pas : cela ferme la configuration démontrée, pas la faille. De même, `ss -Mlnp` montre si un service écoute en MPTCP, mais un résultat vide ne veut pas dire que le serveur est hors de danger. L'équipe sécurité de Go fait la même mise en garde : depuis Go 1.24, les programmes Go ouvrent leurs sockets d'écoute en MPTCP par défaut sous Linux, et seule la mise à jour du noyau règle le problème. ## Mettre à jour le noyau par distribution Le correctif est la mise à jour du noyau, suivie d'un **redémarrage**. Tant que le serveur n'a pas redémarré, l'ancien noyau reste chargé et la faille reste ouverte. Avant de redémarrer un VPS en production, prenez un [snapshot](https://help.onetsolutions.net/fr/vps/snapshot). Si le serveur ne revient pas sur le réseau, la [console KVM](https://help.onetsolutions.net/fr/vps/kvm-console) donne accès à l'écran de démarrage. ### Debian | Version | Paquet corrigé | Bulletin | | - | - | - | | Debian 13 (trixie) | `linux` `6.12.113-1` ou ultérieur | DSA-6568-1 | | Debian 12 (bookworm) | `linux` `6.1.190-1` | DLA-4841-1 | | Debian 12, noyau rétroporté `linux-6.12` | `6.12.113-1~deb12u1` ou ultérieur | DLA-4850-1 | ```bash theme={null} # Debian : installer le noyau corrigé puis redémarrer sudo apt update sudo apt full-upgrade sudo reboot # Après redémarrage : la version du paquet apparaît dans la sortie uname -v ``` ### Ubuntu | Version | Noyau `linux` corrigé | | - | - | | 26.10 | `7.3.0-10.10` | | 26.04 LTS | `7.0.0-43.43` | | 24.04 LTS | `6.8.0-149.149` (noyau HWE : `7.0.0-43.43~24.04.1`) | | 22.04 LTS | `5.15.0-203.213` (noyau HWE : `6.8.0-149.149~22.04.1`) | Les noyaux spécialisés (cloud, lowlatency, FIPS) ont leurs propres versions : consultez la [page Ubuntu de la CVE](https://ubuntu.com/security/CVE-2026-98432). ```bash theme={null} # Ubuntu : installer le noyau corrigé puis redémarrer sudo apt update sudo apt full-upgrade sudo reboot # Après redémarrage, par exemple 6.8.0-149-generic sur 24.04 uname -r ``` ### RHEL, AlmaLinux, Rocky Linux | Version | Noyau corrigé | Bulletin Red Hat | | - | - | - | | RHEL 10.2, AlmaLinux 10 | `kernel-6.12.0-211.72.1.el10_2` | RHSA-2026:93413 | | RHEL 10.3 | `kernel-6.12.0-264.14.1.el10_3` | RHSA-2026:98608 | | RHEL 9, AlmaLinux 9 | `kernel-5.14.0-687.64.1.el9_8` | RHSA-2026:93412 | | RHEL 8, AlmaLinux 8 | `kernel-4.18.0-553.182.1.el8_10` | RHSA-2026:93414 | Les versions AlmaLinux sont celles de l'avis AlmaLinux. Pour Rocky Linux et les versions EUS de RHEL, consultez le [bulletin Red Hat RHSB-2026-016](https://access.redhat.com/security/vulnerabilities/RHSB-2026-016) et l'avis de votre distribution. ```bash theme={null} # RHEL, AlmaLinux, Rocky Linux : installer le noyau corrigé puis redémarrer sudo dnf clean metadata && sudo dnf upgrade sudo reboot # Après redémarrage : noyau chargé et noyaux installés uname -r rpm -q kernel ``` ### Kubernetes Chaque nœud doit recevoir le noyau corrigé et redémarrer. Videz les nœuds un par un pour garder le service : ```bash theme={null} kubectl drain --ignore-daemonsets --delete-emptydir-data # sur le nœud : mise à jour du noyau et redémarrage, comme ci-dessus kubectl uncordon ``` Red Hat précise qu'une règle nftables posée sur un nœud ne filtre que le trafic qui traverse l'espace réseau de l'hôte, pas le trafic entre pods. Un filtrage en bordure, devant le cluster, n'a pas cette limite. ## Mitigation en attendant le correctif Red Hat et Ubuntu publient la même règle nftables : elle rejette les paquets TCP IPv4 entrants qui portent des options IP, ce qui supprime l'entrée dont la faille a besoin. Les options TCP habituelles (timestamps, window scaling) passent toujours, de même que l'IPv6. La règle s'applique sans redémarrer les services. Ses limites : * elle **réduit le risque sans l'éliminer** et ne remplace pas la mise à jour du noyau ; * elle coupe les connexions qui dépendent d'options IPv4 ; * elle couvre l'hôte ; un conteneur qui a son propre réseau doit recevoir la règle séparément, et le trafic entre conteneurs d'un même hôte peut la contourner ; * testez-la sur votre trafic avant de la déployer en production. ### Debian et Ubuntu Procédure publiée par Ubuntu. Elle suppose que le pare-feu est géré par `/etc/nftables.conf`, sans UFW ni firewalld ; Debian utilise le même fichier. ```bash theme={null} # 1. Créer le fichier de règle printf '%s\n' 'table inet cve_2026_98432 { chain input { type filter hook input priority -310; policy accept; ip protocol tcp ip hdrlength > 5 counter drop } }' | sudo tee /etc/cve-2026-98432.nft >/dev/null # 2. Vérifier puis appliquer la règle sudo nft -c -f /etc/cve-2026-98432.nft && sudo nft -f /etc/cve-2026-98432.nft # 3. Conserver la règle au redémarrage (une seule fois) echo 'include "/etc/cve-2026-98432.nft"' | \ sudo tee -a /etc/nftables.conf sudo nft -c -f /etc/nftables.conf && sudo systemctl enable nftables.service ``` ### RHEL, AlmaLinux, Rocky Linux Procédure publiée par Red Hat. Enregistrez la règle dans un fichier `cve-2026-98432.nft` : ```text theme={null} table inet cve_2026_98432 { chain input { type filter hook input priority -310; policy accept; ip protocol tcp ip hdrlength > 5 counter drop } } ``` Puis vérifiez et appliquez-la : ```bash theme={null} sudo nft --check --file cve-2026-98432.nft sudo nft --file cve-2026-98432.nft sudo nft list table inet cve_2026_98432 ``` Cette règle ne survit pas au redémarrage. Pour la rendre persistante, suivez la section « Making the mitigation persistent » du [bulletin RHSB-2026-016](https://access.redhat.com/security/vulnerabilities/RHSB-2026-016) : Red Hat avertit qu'activer `nftables.service` peut entrer en conflit avec firewalld ou une configuration existante. ## Vérifier la mitigation ```bash theme={null} sudo nft list table inet cve_2026_98432 ``` La commande doit afficher la table et sa chaîne `input`. Le compteur de la ligne `drop` indique combien de paquets ont été rejetés. Une erreur signifie que la règle n'est pas chargée. ## Annuler la mitigation Une fois le noyau corrigé chargé (vérifiez avec `uname -r` ou `uname -v`), retirez la règle. ```bash theme={null} # Debian, Ubuntu : retirer la règle et son chargement au démarrage sudo sed -i '\|^include "/etc/cve-2026-98432.nft"$|d' \ /etc/nftables.conf sudo nft delete table inet cve_2026_98432 # RHEL, AlmaLinux, Rocky Linux (règle non persistante) sudo nft delete table inet cve_2026_98432 ``` Si vous avez rendu la règle persistante sur RHEL, suivez la section « Reverting After Patching » du bulletin Red Hat. ## Et après ? La règle nftables n'est qu'un palliatif : la cible reste le noyau corrigé, chargé après redémarrage. Pour une autre faille récente du noyau Linux, lisez [Copy Fail (CVE-2026-31431)](https://blog.onetsolutions.net/fr/copy-fail-cve-2026-31431.md). Pour toute question technique, ouvrez un ticket depuis votre [espace client OnetSolutions](https://help.onetsolutions.net/fr/console/support). This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.