CVE-2026-98432 : vérifier son VPS Ubuntu et réduire son exposition

#Le point au 31 octobre 2026

La fiche Ubuntu consultée le 31 octobre indique encore un correctif en préparation pour le paquet linux d’Ubuntu 26.04 LTS. Ce statut évolue : consultez la ligne correspondant à votre version et à votre famille de noyau avant toute décision.

CVE-2026-98432 concerne la gestion des connexions TCP IPv4 dans le noyau Linux. Un défaut de gestion de mémoire peut être exploité à distance. Le scénario d’exécution de code décrit publiquement utilise un service à l’écoute en MPTCP, mais le défaut sous-jacent ne se limite pas à MPTCP.

Vérifier le statut actuel chez Ubuntu

#Commencer par vérifier son VPS

Ces commandes relèvent le noyau en cours d’exécution, la distribution, deux paramètres réseau et les sockets MPTCP à l’écoute. Elles ne modifient pas la configuration. Si votre version de ss ne prend pas en charge MPTCP, une erreur ne signifie pas que le serveur est protégé.

Comparez le résultat avec le suivi de sécurité de votre distribution. Un numéro de noyau issu d’un message sur les réseaux sociaux ne suffit pas : les distributions peuvent intégrer un correctif dans leurs propres paquets. Un paquet installé n’est pas non plus forcément le noyau actuellement démarré.

uname -r
cat /etc/os-release
sysctl net.mptcp.enabled net.ipv4.tcp_migrate_req
sudo ss -M -l -n -p

#Ce que nous avons fait sur nos deux VPS

Le 30 octobre, nous avons audité nos deux VPS Ubuntu, puis appliqué des mesures temporaires ciblées. Nous avons ajouté un filtre dédié pour les paquets TCP IPv4 contenant des options IP et désactivé la création de sockets MPTCP dans les espaces réseau concernés.

Un service Caddy a été redémarré de manière contrôlée pour recréer ses sockets avec le réglage adapté. Les cinq conteneurs existants ont conservé leurs processus et leur date de démarrage. Nous avons ensuite vérifié de nouvelles connexions SSH et obtenu des réponses HTTPS 200 sur les sept sites contrôlés.

Nous n’avons ni mis à niveau le système, ni redémarré les VPS. Ces résultats décrivent les contrôles effectués après intervention ; ils ne constituent pas une preuve que toutes les formes d’exploitation sont bloquées.

#Filtrer les options IP, avec une règle isolée

Voici la structure du filtre que nous utilisons, avec un nom de table d’exemple. La première règle limite la journalisation ; la seconde bloque tous les paquets correspondants, même lorsque cette limite est atteinte. Les options IP sont différentes des options TCP habituelles, comme MSS ou SACK.

Il s’agit d’un exemple à intégrer au pare-feu existant après vérification, en gardant un accès de secours et un retour arrière ciblé. Ne remplacez pas votre configuration complète. Vérifiez les besoins particuliers de votre réseau, notamment s’il utilise des options IP pour le marquage de sécurité.

Ce filtre vise IPv4. Nous le présentons comme une réduction d’exposition, sans garantie de couverture complète de la vulnérabilité.

table inet cve_2026_98432 {
  chain prerouting {
    type filter hook prerouting priority -310; policy accept;
    ip protocol tcp ip hdrlength > 5 limit rate 5/minute burst 5 packets log prefix "CVE98432 IPopts " level warn
    ip protocol tcp ip hdrlength > 5 counter drop
  }
}

#Désactiver MPTCP si vous ne l’utilisez pas

Si vos services n’ont pas besoin de MPTCP, ce réglage empêche la création de nouvelles sockets MPTCP dans l’espace réseau courant. Il ne ferme pas celles déjà ouvertes. Contrôlez à nouveau les sockets et planifiez le redémarrage des seuls services concernés.

Pour conserver ce choix au démarrage, ajoutez net.mptcp.enabled = 0 dans un fichier dédié de sysctl.d, en vérifiant les réglages existants. La persistance doit ensuite être testée lors d’un redémarrage planifié.

sudo sysctl -w net.mptcp.enabled=0

#Vérifier aussi les services écrits en Go

Go 1.24 a activé MPTCP par défaut pour ListenConfig sur les systèmes compatibles. Un reverse proxy écrit en Go mérite donc une vérification, même si votre application utilise Node.js.

Le réglage ci-dessous modifie ce comportement par défaut lorsqu’il est fourni dans l’environnement du service. Conservez les autres valeurs GODEBUG éventuelles et recréez les sockets du processus concerné. Nous l’avons utilisé pour Caddy ; il ne remplace pas un correctif du noyau.

GODEBUG=multipathtcp=0

#Docker : ne pas s’arrêter au réglage de l’hôte

Le paramètre MPTCP appartient à chaque espace réseau. Une valeur à zéro sur l’hôte ne démontre donc pas que tous les conteneurs ont la même configuration.

Dans notre cas, nous avons vérifié les espaces existants et ajouté un contrôle périodique pour les nouveaux. Un test avec un espace réseau créé après activation a confirmé son traitement. Ce contrôle est périodique : il existe un délai avant son application, ce qui justifie de conserver aussi le filtrage à l’entrée de l’hôte.

Certaines sockets internes déjà ouvertes dans des conteneurs peuvent subsister. Nous avons distingué ces sockets des services publics, au lieu d’assimiler un simple réglage système à une disparition de toutes les sockets.

#Comment nous avons contrôlé la mitigation

Nous avons vérifié le chargement du filtre, ses compteurs, les réglages MPTCP et les services à l’écoute. Un paquet de diagnostic non exploitant a confirmé le passage dans la règle de blocage. Aucun code d’exploitation n’a été exécuté.

Nous avons aussi rouvert une connexion SSH et contrôlé les sites depuis l’extérieur. Les règles antérieures du pare-feu ont été conservées. Les mécanismes de persistance ont été configurés et rechargés, mais nous n’avons pas effectué de test après redémarrage complet des VPS.

Un compteur qui monte prouve qu’un paquet a correspondu à une règle. Il ne prouve ni une tentative d’intrusion, ni une protection totale : nos propres diagnostics peuvent aussi l’incrémenter.

#La suite : démarrer sur un noyau corrigé

La priorité reste le correctif officiel de votre distribution. Lorsqu’il est disponible pour votre système, préparez son installation et le redémarrage nécessaire, puis vérifiez le noyau réellement actif avec uname -r. Décidez ensuite du retrait des mesures temporaires selon le statut officiel et les besoins de vos services.

Ce travail concerne l’infrastructure Linux qui héberge les applications. Une mise à jour npm de PRNext ne peut pas corriger le noyau du VPS. Déployer soi-même implique aussi de suivre cette couche du système et de vérifier les changements en conditions réelles.

Lire aussi : déployer une application sur un VPS