# CVE-2026-98432 : quand l’attente du correctif devient préoccupante Dix-neuf jours se sont écoulés depuis la publication de la fiche Ubuntu sur CVE-2026-98432, le 15 octobre. Pour une équipe exposée sur Internet, cette attente est trop longue et préoccupante. Notre propre intervention a commencé le 30 octobre, avec des mesures temporaires. Le 3 novembre, quatre jours plus tard, nous avons installé le correctif officiel sur nos deux VPS et vérifié leur redémarrage sur le noyau 7.0.0-43-generic. Ces paquets Ubuntu proviennent du dépôt de validation -proposed. La qualification générale annoncée par Ubuntu reste en cours : notre installation vérifiée ne transforme pas ces paquets en une mise à jour déjà diffusée par les canaux stables habituels. ## Ce qui inquiète dans cette attente Une application continue de répondre. Les certificats sont valides. Les déploiements passent. Pourtant, ces résultats ne disent rien sur la correction d’un défaut dans le noyau qui reçoit les connexions réseau. Le fonctionnement visible du service peut donner une impression de normalité alors que le travail de sécurité reste ouvert. Pour un administrateur, chaque jour supplémentaire impose de conserver une décision provisoire, de suivre les annonces et de préparer une intervention. C’est cette période qui nous inquiète. Elle ne justifie ni une accusation de négligence sans preuve, ni l’acceptation d’une mitigation devenue permanente par oubli. ## Un correctif existe, mais son canal de diffusion compte Le communiqué Ubuntu du 2 novembre annonce des correctifs dans le dépôt de validation -proposed pour plusieurs versions prises en charge. Pour Ubuntu 26.04 LTS et le paquet linux, il cite la version 7.0.0-43.43. Le même communiqué indique que la diffusion dans -updates suivra les tests, sans donner de date ferme. Cela change la formulation du problème. Dire qu’aucun correctif n’existe serait inexact. Dire que tous les VPS Ubuntu sont déjà corrigés le serait tout autant. L’existence d’un paquet en validation, sa présence dans les dépôts habituels et son utilisation effective sur une machine sont des faits différents. [communiqué Ubuntu du 2 novembre](https://ubuntu.com/blog/fixes-available-in-proposed-pocket-for-cve-2026-98432) ## -proposed ne remplace pas une validation de production Canonical présente l’accès anticipé aux noyaux proposés comme un choix pour les équipes capables de mener leurs propres tests d’acceptation. Ce canal permet de commencer plus tôt. Il ne signifie pas que la qualification générale est terminée. Sur un VPS qui sert de vraies applications, cette décision concerne aussi le redémarrage, les pilotes, le réseau et le retour arrière. Activer largement un dépôt puis mettre à jour sans examiner les paquets sélectionnés peut étendre l’intervention au-delà du correctif recherché. Cet article ne fournit donc pas de commande générale pour basculer une machine de production vers -proposed. La distinction importante n’est pas « disponible ou indisponible » dans l’absolu. Elle est : disponible dans quel canal, pour quelle distribution, quelle famille de noyau et avec quelle validation ? [l’accès anticipé aux noyaux proposés](https://canonical.com/blog/accelerating-delivery-of-cve-fixes-with-a-new-kernel-release-strategy) ## Nos deux VPS utilisent le noyau corrigé Le VPS TinyDigit est passé de 7.0.0-38-generic à 7.0.0-43-generic. Le VPS PRNext est passé de 7.0.0-28-generic à 7.0.0-43-generic. Dans les deux cas, nous avons installé quatre paquets de noyau Ubuntu en version 7.0.0-43.43, puis contrôlé le noyau réellement démarré après redémarrage. L’installation est restée ciblée sur ces paquets, sans mise à niveau de distribution ni activation globale de -proposed. Les anciens noyaux sont conservés comme solution de secours au démarrage. Le filtrage réseau et les réglages MPTCP temporaires sont également maintenus pendant ce suivi. Après les redémarrages, nous avons rouvert une connexion SSH sur chaque serveur et vérifié les réponses HTTPS des points d’accès PRNext et TinyDigit contrôlés. Les cinq conteneurs d’applications d’origine sont présents et prêts ; leurs cinq alias natifs répondent également en HTTPS. Une dépendance externe reste indisponible ; le rétablissement applicatif complet reste à vérifier. ## Le noyau démarré reste le point de contrôle Le paquet installé sur le disque et le noyau actuellement exécuté peuvent être différents. Après une intervention, le contrôle doit porter sur le système réellement démarré, puis sur l’accès SSH, le HTTPS et les applications qu’il héberge. Un message de succès du gestionnaire de paquets ne clôt pas à lui seul ce travail. Ces deux commandes ne modifient pas le serveur. Elles permettent de commencer la comparaison avec le suivi officiel de la distribution. Un numéro pris isolément, sans connaître le paquet et les correctifs intégrés par la distribution, ne suffit pas pour conclure. ```bash uname -r cat /etc/os-release ``` ## Ne pas confondre mitigation et réparation Notre premier guide documente les mesures temporaires appliquées le 30 octobre et les contrôles réalisés ensuite. Ce compte rendu reste historique : il ne prouve pas l’état actuel de chaque VPS. La désactivation de MPTCP ne corrige pas le défaut sous-jacent. Le filtrage ciblé des options IPv4 est lui aussi présenté avec des limites dans le suivi Ubuntu. Une règle chargée, un compteur de paquets ou un site accessible ne constituent pas une garantie contre toutes les formes d’exploitation. [premier guide](/fr/blog/cve-2026-98432-vps-ubuntu-mitigation) ## Ce que nous attendons d’un suivi de sécurité Il est légitime d’exiger un état lisible : ce qui est corrigé, ce qui est encore testé et ce qui reste à faire sur les machines. Il est tout aussi important de reconnaître le coût d’une mise à jour du noyau déployée sans validation suffisante. L’urgence et la stabilité font partie de la même décision. Notre ligne reste simple : ne pas laisser le provisoire disparaître du suivi. La fin de l’intervention doit être une version corrigée effectivement utilisée et des services vérifiés, pas seulement une annonce rassurante. Une mise à jour npm de PRNext ne peut pas accomplir cette étape à la place du système Linux. ## Sources [Ubuntu · CVE-2026-98432](https://ubuntu.com/security/CVE-2026-98432) [Ubuntu · Fixes available in -proposed, 2 November 2026](https://ubuntu.com/blog/fixes-available-in-proposed-pocket-for-cve-2026-98432) [Canonical · Kernel release strategy](https://canonical.com/blog/accelerating-delivery-of-cve-fixes-with-a-new-kernel-release-strategy) [Ubuntu · SRU verification](https://ubuntu.com/project/docs/SRU/reference/sru-verification/) Published: 2026-11-03 Modified: 2026-11-03 Author: PRNext --- Language: fr Canonical: https://prnext.dev/fr/blog/cve-2026-98432-ubuntu-attente-correctif-noyau Index: https://prnext.dev/llms.txt