FAQ Instructions simples pour travailler avec le service Profitserver
Entrée FAQ Vulnérabilité critique du noyau Linux CVE-2026-98432 : Comment vérifier et mettre à jour votre VPS

Vulnérabilité critique du noyau Linux CVE-2026-98432 : Comment vérifier et mettre à jour votre VPS


En octobre 2026, une vulnérabilité critique, CVE-2026-98432 , a été découverte dans le noyau Linux. Classée 9.8 sur 10 sur l'échelle CVSS, elle affecte la gestion des connexions TCP IPv4 entrantes et permet, sous certaines conditions, à un attaquant d'obtenir un accès root à un serveur à distance, sans mot de passe ni intervention de l'administrateur.

Vous trouverez ci-dessous la liste des personnes concernées, la procédure de vérification de votre serveur et les mesures de protection à prendre. Toutes les commandes doivent être exécutées en tant que superutilisateur (root) ou avec les privilèges root. sudo.

La vulnérabilité en bref

  • Qu'est-ce que c'est: Une vulnérabilité de type « use-after-free » (utilisation après libération) dans le code établissant les connexions TCP IPv4, due à une condition de concurrence, permet à l'attaquant d'envoyer des paquets spécialement conçus à n'importe quel port TCP ouvert.
  • Noyaux concernés : chaque version depuis Linux 4.4, ce qui signifie pratiquement toutes les distributions actuelles.
  • IPv6 n'est pas affecté par le bug principal.
  • À quel point la menace est-elle réelle ? Des chercheurs d'Anthropic ont démontré qu'une chaîne d'exploitation fonctionnelle permettait d'obtenir un accès root à un serveur dont le protocole TCP multipath (MPTCP) était activé, en environ 53 minutes. Le code d'exploitation n'a pas été publié.
  • Attaques en milieu sauvage : Au 1er novembre 2026, aucune exploitation n'a été signalée. C'est une raison de procéder à la mise à jour sereinement, et non de la reporter.

Les services Go présentent un risque spécifique. Depuis Go 1.24, les programmes serveur sous Linux écoutent par défaut sur les ports via MPTCP lorsque le noyau l'autorise. Un administrateur peut même ignorer que son serveur accepte de telles connexions. Parmi les logiciels populaires, Xray fonctionne de cette manière ; ses développeurs ont déjà publié une version d'urgence, la v26.10.31, qui désactive MPTCP par défaut.

Chaque VPS exécute son propre noyau ; vous devez donc mettre à jour vous-même le noyau de votre serveur. Nous nous chargeons de la mise à jour des nœuds de virtualisation.

Existe-t-il une solution pour votre système ?

Situation au 1er novembre 2026. Des correctifs sont déployés presque quotidiennement ; consultez les liens à la fin de cet article pour connaître l’état actuel.

Système Statut Noyau fixe
Debian 13 Parfaitement fixé linux 6.12.113-1
Debian 12 Parfaitement fixé linux 6.1.190-1
Ubuntu 22.04, 24.04, 26.04 Correction en cours Pas encore — utilisez la protection temporaire
AlmaLinux 8, 9, 10 Correction dans le dépôt de test 8: 4.18.0-553.180.2.el8_10
9: 5.14.0-687.61.2.el9_8
10: 6.12.0-211.69.2.el10_2
Rocky Linux, RHEL 8, 9, 10 Aucune solution pour l'instant Utilisez la protection temporaire
Oracle Linux 7–10 (UEK) Parfaitement fixé via une mise à jour standard
SUSE / openSUSE Leap 16 Parfaitement fixé via une mise à jour standard

Étape 1. Vérifiez quel noyau vous utilisez.

Déterminez la version du noyau en cours d'exécution :

uname -r

Le numéro de version seul ne vous apprend rien : les distributions intègrent des correctifs à leur propre noyau sans modifier la version de base. Il est plus fiable de consulter le journal des modifications du paquet noyau ; s’il mentionne le numéro CVE, le correctif est déjà installé.

Debian et Ubuntu :

apt changelog linux-image-$(uname -r) 2>/dev/null | grep CVE-2026-98432

Sur Debian, le uname -v Cette commande affiche également la version complète du paquet du noyau en cours d'exécution : comparez-la avec le tableau ci-dessus.

AlmaLinux, Rocky Linux, RHEL, Oracle Linux :

rpm -q --changelog kernel-core-$(uname -r) | grep CVE-2026-98432

Si la commande n'affiche rien, le noyau en cours d'exécution est vulnérable.

Ensuite, vérifiez quels services acceptent les connexions via MPTCP. Les serveurs de ce type étaient la cible de l'attaque présentée :

ss -lnMp

Une sortie vide signifie qu'il n'y a pas d'écouteurs MPTCP.

Étape 2. Installez le noyau corrigé

Effectuez une sauvegarde ou un instantané de votre serveur avant de mettre à jour le noyau.

Debian 12 et 13

Les noyaux corrigés se trouvent dans le dépôt de sécurité. Assurez-vous qu'il est activé :

grep -r security.debian.org /etc/apt/sources.list /etc/apt/sources.list.d/

Si aucun résultat n'est trouvé, ajoutez le security.debian.org Dépôt pour votre version. Ensuite, mettez à jour le système :

apt update
apt full-upgrade
reboot

Ubuntu

Les correctifs du noyau n'ont pas encore été publiés. Vérifiez les mises à jour :

apt update
apt list --upgradable | grep linux-image

Si votre serveur est connecté à Ubuntu Pro, vous pouvez consulter le plan de réparation :

pro fix CVE-2026-98432 --dry-run

Une fois le correctif publié, installez-le et redémarrez :

apt update
apt full-upgrade
reboot

D’ici là, veillez à appliquer la protection temporaire de l’étape 3.

AlmaLinux 8, 9, 10

Les noyaux corrigés ne sont actuellement disponibles que dans le dépôt de test. Installez-les si vous êtes à l'aise avec cette opération sur un serveur de production, et veillez à prendre un instantané avant la mise à jour :

dnf install -y almalinux-release-testing
dnf update 'kernel*' --enablerepo=almalinux-testing
dnf config-manager --disable almalinux-testing
reboot

Après le redémarrage, comparez uname -r avec les versions indiquées dans le tableau ci-dessus. Si vous préférez ne pas installer les paquets de test, appliquez la protection temporaire et attendez que le correctif soit disponible dans le dépôt principal.

Rocky Linux et autres systèmes basés sur RHEL

Il n'existe pas encore de solution. Vous pouvez suivre son évolution avec :

dnf --refresh updateinfo info --all --cves CVE-2026-98432

Une fois le correctif publié :

dnf update kernel
reboot

Après la mise à jour : un redémarrage est nécessaire

Le nouveau noyau ne sera effectif qu'après un redémarrage. Pour vérifier si un redémarrage est nécessaire :

# Debian and Ubuntu
[ -f /var/run/reboot-required ] && echo "Reboot required"

# AlmaLinux, Rocky, RHEL
needs-restarting -r

Après le redémarrage, répétez la vérification de l'étape 1.

Étape 3. Protection temporaire jusqu'à ce qu'un noyau corrigé soit disponible.

Ces mesures réduisent le risque mais ne remplacent pas une mise à jour du noyau.

Bloquer les paquets de déclenchement

Cette attaque exploite des paquets TCP comportant des options IP dans l'en-tête IPv4. Ces paquets sont quasiment inexistants dans le trafic normal, et la RFC 7126 recommande déjà de les bloquer. La règle nftables ci-dessous bloque tous les paquets TCP IPv4 entrants comportant des options, sans affecter les protocoles IPv6, UDP ou ICMP. Elle fonctionne en parallèle avec ufw et firewalld.

Installez nftables s'il n'est pas déjà installé :

# Debian and Ubuntu
apt install -y nftables

# AlmaLinux, Rocky, RHEL
dnf install -y nftables

Créez le fichier de règles :

cat > /etc/cve-2026-98432.nft <<'EOF'
table ip cve_2026_98432 {
    chain pre {
        type filter hook prerouting priority -300; policy accept;
        meta l4proto tcp ip hdrlength gt 5 counter drop
    }
}
EOF

Pour que la règle soit rétablie après chaque redémarrage, créez un service systemd :

cat > /etc/systemd/system/cve-2026-98432.service <<'EOF'
[Unit]
Description=Mitigation for CVE-2026-98432
After=network-pre.target nftables.service firewalld.service ufw.service

[Service]
Type=oneshot
RemainAfterExit=yes
ExecStartPre=-/usr/sbin/nft delete table ip cve_2026_98432
ExecStart=/usr/sbin/nft -f /etc/cve-2026-98432.nft
ExecStop=/usr/sbin/nft delete table ip cve_2026_98432

[Install]
WantedBy=multi-user.target
EOF

systemctl daemon-reload
systemctl enable --now cve-2026-98432.service

Vérifiez que la règle est chargée :

nft list table ip cve_2026_98432

Si vous redémarrez le service nftables avec une commande globale flush ruleset règle, exécuter systemctl restart cve-2026-98432 après.

Important : n’appliquez pas cette règle aux réseaux utilisant des étiquettes CIPSO (SELinux ou Smack NetLabel) ; les options IP y sont utilisées normalement. Si votre serveur achemine le trafic d’autres machines, la règle bloquera également leurs paquets TCP comportant des options IP.

Désactivez MPTCP si vous n'en avez pas besoin.

sysctl -w net.mptcp.enabled=0
echo "net.mptcp.enabled = 0" > /etc/sysctl.d/99-disable-mptcp.conf

Ce paramètre empêche uniquement New La création de sockets MPTCP est empêchée. Les services déjà en cours d'exécution continueront d'écouter via MPTCP ; redémarrez donc tous les services listés par ss -lnMp et assurez-vous que sa sortie est maintenant vide.

Sur AlmaLinux, MPTCP est désactivé par défaut, sauf si vous l'avez activé vous-même.

Désactiver MPTCP dans les programmes Go

Pour les services développés avec Go 1.24 ou une version ultérieure, vous pouvez désactiver MPTCP à l'aide d'une variable d'environnement. Par exemple, pour un service appelé myservice:

systemctl edit myservice

Ajoutez les éléments suivants au fichier qui s'ouvre :

[Service]
Environment=GODEBUG=multipathtcp=0

Redémarrez ensuite le service :

systemctl restart myservice

Mise à jour des rayons X

Si votre serveur utilise Xray, mettez-le à jour vers la version 26.10.31 ou ultérieure. La version précédente, la 26.10.29, a été retirée par ses développeurs. Cette mise à jour désactive MPTCP mais ne corrige pas le noyau ; une mise à jour de ce dernier reste donc nécessaire.

Vérifier un autre paramètre

Une seconde méthode d'exploitation, plus ciblée, nécessite l'activation de la migration des requêtes. Celle-ci est désactivée par défaut ; assurez-vous qu'elle l'est.

sysctl net.ipv4.tcp_migrate_req

La commande devrait imprimer 0.

Limitez l'accès à vos services

Fermez tous les ports du pare-feu qui ne doivent pas être accessibles depuis Internet. Dans la mesure du possible, n'ouvrez les services d'administration (SSH, panneaux de contrôle, bases de données) qu'aux adresses IP de confiance.

Étape 4. Après l'installation du noyau corrigé

  1. Redémarrez le serveur et utilisez les commandes de l'étape 1 pour confirmer que le noyau corrigé est en cours d'exécution.
  2. Vous pouvez supprimer la règle temporaire :
    systemctl disable --now cve-2026-98432.service
    rm /etc/systemd/system/cve-2026-98432.service /etc/cve-2026-98432.nft
    systemctl daemon-reload

  3. Si vous avez besoin de MPTCP, rétablissez le paramètre : supprimer /etc/sysctl.d/99-disable-mptcp.conf et courir sysctl -w net.mptcp.enabled=1.

Si quelque chose ne va pas

Si votre serveur ne démarre pas après la mise à jour du noyau, connectez-vous via la console VNC du panneau de configuration et sélectionnez le noyau précédent dans le menu de démarrage. Si vous n'êtes pas sûr de pouvoir effectuer cette opération vous-même ou si vous avez besoin d'aide pour la mise à jour, contactez notre équipe d'assistance.


Demandez-nous des informations sur VPS

Nous sommes toujours prêts à répondre à vos questions à toute heure du jour ou de la nuit.