← Actualités

3 novembre 20264 min de lecture

Noyau Linux : la faille TCP CVE-2026-98432 impose de mettre à jour ses serveurs

Une faille critique du noyau Linux, référencée CVE-2026-98432, touche le code qui établit les connexions TCP en IPv4. Présente depuis Linux 4.4, elle est notée 9,8 sur 10. Des chercheurs d'Anthropic ont montré qu’un attaquant distant, sans identifiant, peut s’en servir pour exécuter une commande en root, c’est-à-dire avec les pleins pouvoirs d’administrateur. Serveurs de PME, serveurs virtuels loués (VPS) et hyperviseurs installés à domicile doivent recevoir un noyau corrigé.

Le bug relève du « use-after-free » : le noyau libère une zone de mémoire alors qu’un autre cœur du processeur peut encore la lire. Cette zone contient ici les options IP d’une connexion entrante en cours d’établissement. Selon l'annonce de l’équipe CVE du noyau, le correctif retarde la libération jusqu’à ce qu’aucun cœur ne s’en serve plus. IPv6 échappe à ce scénario, car les options y sont copiées pour chaque connexion.

Une attaque démontrée en laboratoire

Tux, par Larry Ewing (lewing@isc.tamu.edu) et The GIMP, avec Simon Budig et Garrett LeSage — réutilisation libre sous réserve d’attribution — via Wikimedia Commons

Anthropic a détaillé l’attaque le 27 octobre 2026, dans un article de recherche. Après des instructions initiales, son modèle d’IA Claude a écrit un exploit, c’est-à-dire un programme d’attaque. Il vise les serveurs Linux dotés d’un service à l’écoute en Multipath TCP (MPTCP), une extension qui répartit une même connexion sur plusieurs chemins réseau. L’exploit contourne d’abord la protection KASLR, qui place le noyau à une adresse mémoire aléatoire. Il aboutit ensuite à l’exécution en root d’une commande choisie par l’attaquant.

L’opération demande de la patience. Lors du test, il a fallu 48 minutes pour obtenir une adresse du noyau, puis cinq de plus pour exécuter la commande. Une tentative ratée ne fait pas planter le serveur : seule la prise de contact TCP échoue, et l’attaquant peut recommencer. IT-Connect attribue la découverte à Xinyang Ge, chercheur chez Anthropic. Le site relève que l’entreprise n’a publié ni le code de l’exploit, ni la version du noyau, ni la configuration testée.

MPTCP n’a rien d’un réglage exotique. Depuis Go 1.24, les programmes écrits dans ce langage l’activent par défaut sur leurs points d’écoute sous Linux. L'équipe de sécurité de Go propose de le couper avec la variable d’environnement GODEBUG=multipathtcp=0, mais juge qu’un noyau corrigé reste la meilleure solution. Elle rappelle que le bug de fond n’est pas propre à MPTCP. AlmaLinux, qui désactive MPTCP d’office, le confirme : l’erreur se loge dans le code TCP IPv4 ordinaire, et les systèmes sans MPTCP ont aussi besoin du correctif.

Désactiver MPTCP programme par programme est une parade fragile.

— L’équipe de sécurité du langage Go (traduction de la rédaction)

Une gravité d’abord sous-estimée

L’évaluation de la gravité a varié. Le 29 octobre 2026, Red Hat attribuait à la faille une note de 5,9 sur 10 et une sévérité modérée, rapporte IT-Connect. L’équipe CVE du noyau lui attribue 9,8, et le bulletin RHSB-2026-016 de Red Hat, mis à jour le 2 novembre 2026, la classe désormais critique. Red Hat y précise qu’un attaquant distant et non authentifié pourrait l’exploiter, même si l’opération exige un minutage précis des requêtes réseau.

Le 2 novembre 2026, selon IT-Connect, la faille ne figurait pas au catalogue KEV (vulnérabilités exploitées connues) de l’agence américaine de cybersécurité CISA. Aucune exploitation dans la nature, c’est-à-dire lors d’attaques réelles, n’était signalée. À notre avis, ce répit est fragile : la description publique de l’attaque et le correctif lui-même désignent clairement le code en cause.

Les correctifs, distribution par distribution

Le noyau officiel est corrigé, notamment, dans ses versions 6.1.190, 6.12.113 et 7.3. Red Hat a publié le 1er novembre 2026 des noyaux corrigés pour RHEL 8, 9 et 10, et Debian 13 est aussi corrigé, d’après IT-Connect. AlmaLinux a d’abord placé les siens dans un dépôt de test le 30 octobre 2026, puis les a intégrés à ses mises à jour habituelles pour toutes ses éditions maintenues. L’hyperviseur libre Proxmox VE a livré son noyau corrigé le 31 octobre 2026. Sa référence : proxmox-kernel-7.0.14-25-pve.

Ubuntu fait figure de retardataire. Le 2 novembre 2026, Canonical, son éditeur, n’annonçait qu’un correctif en préparation pour les versions 22.04 à 26.10. Ubuntu 20.04 et plusieurs versions plus anciennes restaient listées comme vulnérables. En attendant, Red Hat décrit une règle pour nftables, le pare-feu intégré à Linux, qui écarte les paquets TCP IPv4 porteurs d’options IP. L’éditeur prévient qu’elle ne remplace pas le correctif et peut perturber des services nécessaires. La fiche d’Ubuntu reprend cette parade : elle réduit le risque sans empêcher totalement l’exploitation, et doit être appliquée séparément aux conteneurs dotés de leur propre réseau.

Le geste est simple pour une TPE, une association ou un particulier qui gère un serveur, un VPS ou un Proxmox à la maison : appliquer les mises à jour du noyau proposées par la distribution, puis redémarrer. Un noyau corrigé ne protège qu’après un redémarrage. La commande uname -r affiche ensuite la version active. Sous Ubuntu, il faut guetter l’arrivée du correctif et, d’ici là, tester puis appliquer la parade nftables. Les NAS et routeurs dont le système Linux est fourni par un fabricant dépendent de ses mises à jour : mieux vaut consulter ses bulletins de sécurité.

Parlons de votre besoin

Aide entièrement gratuite et bénévole, selon nos disponibilités. Professionnel ou particulier, la démarche est la même.