CVE-2026-98432 et CVE-2026-106378 : correctifs Linux et Chrome

CVE-2026-98432 touche le traitement TCP sur IPv4 du noyau Linux ; CVE-2026-106378 concerne le bac à sable de Chrome sur macOS avant la version 155.0.8059.39. Vérifiez les hôtes Linux à l’aide de l’avis du fournisseur de leur noyau, et les navigateurs sur Mac à l’aide de l’historique des mises à jour de Chrome. Après la mise à jour, vérifiez la version active : un téléchargement ne suffit pas à établir que les correctifs sont actifs.

L’alerte de Derek Ross du 30 octobre a attiré l’attention des exploitants de serveurs, de nœuds et de relais sur le problème Linux. Le message de PWN.AI du 30 octobre met en avant une autre faille, qui permet de sortir du bac à sable du processus GPU de Chrome. Pour une startup, il faut déterminer quelles machines, quels paquets et quelles installations du navigateur nécessitent une intervention.

L’annonce de la CVE Linux date du 15 octobre ; la fiche CVE de Chrome publiée par Google remonte au 6 octobre. Les messages d’aujourd’hui remettent en lumière des vulnérabilités et des correctifs déjà connus.

État vérifié le 30 octobre 2026. Les liens des fournisseurs ci-dessous font référence pour connaître la situation actuelle. La disponibilité des paquets peut évoluer après cet état des lieux.

Qu’est-ce que CVE-2026-98432, et permet-elle une prise de contrôle à distance ?

Le défaut confirmé concerne la durée de vie de la mémoire pendant le traitement des connexions TCP. Traitez-le comme une vulnérabilité grave du noyau, tout en distinguant le bogue documenté des affirmations sur une prise de contrôle à distance reproductible.

Une utilisation de mémoire libérée se produit lorsque du code accède à une zone de mémoire qui a déjà été libérée. Ici, des traitements concurrents peuvent encore lire les options d’un socket IPv4 après leur libération par un autre chemin d’exécution. Le correctif du projet Linux modifie deux chemins de destruction pour différer cette libération jusqu’à la fin d’une période de grâce RCU. RCU, pour read-copy-update, est un mécanisme du noyau qui laisse les lectures en cours se terminer avant de récupérer la mémoire.

Au 30 octobre, Ubuntu attribue un score CVSS 3.1 de 9.8, et l’avis actuel de Red Hat affiche un score provisoire de 9.8. Red Hat décrit un risque de plantage, de déni de service ou de corruption de la mémoire. Amazon Linux attribue un score de 8.1. Précisez le fournisseur et la version du système de notation pour chaque score ; un score de gravité ne prouve pas qu’une prise de contrôle est reproductible sur chaque déploiement touché.

Les recherches publiées par Anthropic le 27 octobre présentent une démonstration d’exécution de commandes avec les droits root sur un serveur Linux doté d’un socket en écoute Multipath TCP (MPTCP), sans identifiants ni interaction de l’utilisateur. Il s’agit d’un résultat concret d’exécution à distance, pour une configuration déterminée. Il ne prouve pas que l’exploitation est fiable sur tous les noyaux et déploiements touchés.

L’avis du 29 octobre de l’équipe de sécurité de Go explique pourquoi des équipes peuvent avoir de tels sockets sans le savoir : Go 1.24 a activé MPTCP par défaut pour les sockets en écoute sous Linux, sous réserve des réglages du programme et de l’environnement d’exécution. L’équipe recommande un noyau corrigé. Elle précise que désactiver MPTCP neutralise le chemin d’exploitation démontré, mais ne corrige pas le défaut IPv4 sous-jacent.

Dans le dossier d’incident, distinguez trois questions : le code vulnérable est-il présent, le trafic concerné peut-il l’atteindre, et quelle exploitation a été démontrée dans votre environnement ? Vous pouvez donner la priorité au correctif avant d’avoir toutes les réponses. Une réponse inconnue ne signifie ni que la machine est saine, ni qu’elle a été compromise.

Quelles versions du noyau Linux sont touchées et corrigées ?

Les numéros de version du projet Linux identifient les correctifs dans ses différentes branches. Les paquets des distributions demandent une vérification distincte, car les fournisseurs peuvent rétroporter un correctif tout en conservant une ancienne version de base.

La fiche actuelle de l’autorité d’attribution des CVE Linux fait remonter le problème à Linux 4.4 et indique les premières versions corrigées suivantes, vérifiées le 30 octobre :

Utilisez la dernière version prise en charge de la branche que vous maintenez. Ces seuils concernent les branches du projet Linux ; ils ne constituent pas une règle de détection universelle pour Ubuntu, Debian, RHEL ou une image cloud. Les avis des fournisseurs déterminent quels paquets des distributions contiennent la correction.

Un rétroportage applique une correction à une base de code plus ancienne et toujours maintenue. Un paquet fournisseur dont le numéro semble inférieur peut donc contenir le correctif. À l’inverse, comparer uniquement la valeur de uname -r à une version citée sur un réseau social peut conduire à une conclusion erronée.

Conservez les références complètes du paquet : version de la distribution, famille ou variante du noyau, architecture et révision du paquet. Un noyau cloud, un noyau générique et un noyau destiné à la prise en charge de matériel récent peuvent suivre des calendriers de mise à jour différents au sein d’une même distribution.

La description du projet Linux précise aussi qu’IPv6 n’est pas concerné par le premier problème, tout en signalant un problème connexe de migration IPv6 qui nécessite un correctif distinct. Cette précision ne signifie pas que passer un service à IPv6 résout tous les problèmes de noyau pertinents. Consultez l’avis applicable à votre configuration.

Où en sont les correctifs Ubuntu, Debian, RHEL et cloud ?

L’état d’un correctif concerne un produit et une série de paquets précis. Ce tableau, daté, aide à repérer la bonne série ; il ne permet pas d’établir l’état d’un hôte en fonctionnement.

Sources : suivi CVE d’Ubuntu, suivi de sécurité de Debian, suivi CVE d’Amazon Linux, avis de Red Hat et répertoire CVE d’Oracle Linux.

Les numéros Debian indiqués ici sont des versions de paquets sources, pas les valeurs littérales attendues dans la sortie de uname -r. Le suivi d’Ubuntu contient de nombreuses autres variantes. Les errata UEK d’Oracle ne prouvent pas que toutes les séries de noyaux Oracle sont corrigées.

Si votre paquet exact ne figure pas dans cet état des lieux, ouvrez le suivi de son fournisseur. Indiquez que son état est inconnu tant que vous n’avez pas établi la correspondance. L’absence d’un paquet dans le tableau succinct d’un article ne prouve pas qu’il est sûr.

Comment vérifier le noyau réellement exécuté par votre serveur ?

Relevez d’abord le système d’exploitation et la version en cours d’exécution. Rapprochez ensuite ces informations de la fiche du paquet chez le fournisseur.

Ces commandes en lecture seule constituent un point de départ sur un hôte Linux :

cat /etc/os-release
uname -r

Conservez la sortie avec l’identité de l’hôte et l’heure de vérification. Exécutez les vérifications dans l’environnement dont vous devez établir le noyau, puis identifiez qui gère ses mises à jour. Pour un service managé, cela peut nécessiter une confirmation du prestataire plutôt qu’un accès au gestionnaire de paquets.

Utilisez ensuite les outils de votre distribution pour identifier les paquets de noyau installés et leurs révisions complètes. Comparez le paquet applicable à la version corrigée indiquée par le fournisseur. Une exécution réussie du gestionnaire de paquets constitue un élément utile pour confirmer l’installation ; il reste à établir quel noyau est actif.

Distinguez bien ces états :

Après une mise à jour classique du noyau, suivez la procédure de redémarrage du fournisseur et relevez de nouveau la version exécutée. Si vous appliquez des correctifs à chaud, obtenez une confirmation explicite que le prestataire couvre cette CVE sur ce noyau. Un abonnement à un service de correctifs à chaud ne répond pas, à lui seul, à cette question.

Appliquez la même distinction aux machines de remplacement. Vérifiez l’image ou le modèle utilisé pour créer les hôtes, puis inspectez une instance nouvellement lancée. Sinon, une correction réussie sur les serveurs actuels peut laisser ceux de demain sans vérification.

Que faire en attendant un correctif fournisseur ?

Limitez l’exposition à la vulnérabilité, désignez qui prendra la prochaine décision et gardez les systèmes non corrigés clairement identifiés. Les mesures temporaires nécessitent leur propre vérification et un plan de retrait.

Commencez par un inventaire de l’exposition : quels hôtes acceptent des connexions TCP, depuis quels réseaux, et à travers quelles protections ? Incluez les interfaces d’administration et les services d’infrastructure, en plus de l’application publique. Un nom d’hôte ne décrit pas, à lui seul, le chemin emprunté par le trafic jusqu’à la machine.

Examinez si des services inutiles peuvent être arrêtés ou leur accès restreint sans perturber les opérations nécessaires. Décrivez précisément le résultat : quels réseaux sources peuvent encore atteindre quel service en écoute ? Vérifiez-le depuis le point du réseau concerné. Considérez cette mesure comme une réduction de l’exposition et consignez le risque résiduel.

L’avis de Red Hat indique qu’aucune mesure d’atténuation n’est actuellement jugée adaptée selon ses critères publiés. Les recommandations de l’équipe CVE du noyau privilégient la mise à jour vers une version stable prise en charge et déconseillent l’application sélective de correctifs isolés. Préférez la procédure de mise à jour prise en charge par le fournisseur à une modification artisanale du noyau.

L’alerte sur le réseau social évoque aussi le filtrage des options IPv4 et la désactivation de Multipath TCP, ou MPTCP. L’avis de Go confirme l’intérêt de vérifier les sockets MPTCP en écoute, mais prévient qu’une configuration programme par programme est fragile et que le défaut sous-jacent ne se limite pas à MPTCP. Avant d’adopter une solution provisoire, établissez le chemin de code qu’elle couvre, le trafic qui atteint encore l’hôte et la prise en charge de cette mesure par le fournisseur pour votre configuration.

Si l’équipe modifie les protections réseau, préservez un accès de récupération, testez les connexions nécessaires et consignez la procédure de retour arrière. Une règle de pare-feu copiée ne peut pas évaluer votre politique existante ni ses dépendances. Demandez au responsable du réseau d’approuver la modification précise et d’en vérifier l’effet.

Attribuez chaque cas en attente à un responsable et fixez l’heure de la prochaine consultation de l’avis. Faites remonter les décisions qui nécessitent une interruption de service, une intervention du prestataire ou l’acceptation d’une période de risque résiduel. Notre guide d’escalade des correctifs de sécurité explique comment expliciter cette décision.

Que faut-il mettre à jour pour la CVE-2026-106378 de Chrome ?

Sur macOS, mettez Chrome à jour vers la version stable actuellement prise en charge, puis relancez-le. La fiche CVE de Google indique que les versions antérieures à 155.0.8059.39 sont touchées par ce problème. Ce seuil historique de correction n’est pas une recommandation de conserver une ancienne version du navigateur.

La publication de Google pour la version stable du 6 octobre répertoriait déjà cette CVE parmi les correctifs de Chrome 155. Le message du 30 octobre présente les recherches ; ce n’est pas la date de publication du correctif.

Dans les recherches de PWN.AI, du code déjà exécuté dans le processus GPU de Chrome pouvait envoyer des frappes synthétiques par l’intermédiaire de WindowServer, sous macOS. La démonstration a ouvert Spotlight et lancé Calculatrice hors du bac à sable GPU. Les chercheurs précisent qu’ils partent d’une exécution de code natif dans le processus auxiliaire GPU. Leur test démontre donc une étape d’évasion, sans fournir la compromission initiale du navigateur.

La description CVE de Google pose comme prérequis un processus de rendu déjà compromis et classe le problème au niveau Medium selon le système de gravité de Chromium. Conservez cette description du fournisseur à côté du point de départ précis des chercheurs dans le processus GPU. Aucune des deux ne justifie de présenter ce seul bogue comme une attaque complète et universelle déclenchée par la simple visite d’une page. Fiche CVE de Google.

Le correctif de Chromium traite l’autorisation héritée dans TCC, le système de gestion des autorisations de confidentialité de macOS. Sa description explique que le lancement direct de l’exécutable Chromium depuis un autre processus peut transmettre les autorisations de ce parent à Chromium et à ses processus enfants. Le processus enfant GPU ne devrait pas hériter de cette autorisation. Le mode de lancement et les permissions existantes comptent donc dans le comportement décrit.

Désignez un responsable de la mise à jour du navigateur et consignez les preuves :

Dans Chrome, ouvrez Aide → À propos de Google Chrome, laissez la mise à jour prise en charge se terminer et relancez le navigateur lorsque cela vous est proposé. Vérifiez ensuite la version affichée. Les instructions de mise à jour de Chrome fournies par Google détaillent la procédure. Séparez cette vérification du déploiement du noyau Linux : les logiciels et les étapes d’activation sont différents.

Quelles preuves permettent de clore les tâches de correction de ces CVE ?

Clôturez la correction d’un hôte lorsque vous pouvez relier son identité, le correctif applicable, le noyau actif et le résultat de la vérification. Conservez les exceptions à part pour qu’un déploiement terminé ne masque pas une machine encore en attente d’intervention.

Pour Chrome, reprenez les mêmes champs : Mac, installation du navigateur, avis et version après relance. Consignez le redémarrage du noyau et la relance du navigateur dans leurs tâches respectives.

Utilisez une fiche courte comme celle-ci. Il s’agit d’un modèle opérationnel, pas d’une exigence fournisseur :

• Hôte et responsable : identité stable de la machine, service, environnement et personne chargée du traitement.
• Applicabilité : distribution, famille de noyau, révision complète du paquet et URL de l’avis.
• Action : mise à jour ou mesure temporaire approuvée, avec l’heure de réalisation.
• Activation : version exécutée après redémarrage, ou couverture explicite par un correctif à chaud pris en charge.
• Vérification : personne ayant examiné les preuves, date de cet examen et bon fonctionnement des services nécessaires.
• Travail restant : hôtes dont la mise à jour est reportée, mesures temporaires, images de remplacement et prochaine vérification.

Pour un parc de machines, indiquez les hôtes traités et ceux en attente à partir du même inventaire. Une phrase comme « la mise à jour du noyau est déployée » laisse trop de place à l’interprétation. Précisez quelles machines exécutent la version corrigée, lesquelles l’ont installée sans l’activer, et lesquelles restent en attente.

Prenons une application hypothétique sur trois serveurs. Deux machines redémarrent sur le noyau corrigé ; sur la troisième, le paquet est installé mais le créneau de maintenance a été manqué. Laissez le dossier de cette troisième machine ouvert, désignez son responsable et fixez une nouvelle heure d’activation. L’installation du paquet a réussi, mais cet hôte ne remplit pas la même condition de clôture que les deux autres.

Si un chercheur a signalé l’exposition, accusez réception de son rapport et expliquez ce qui a été vérifié sans dévoiler de détails d’infrastructure inutiles. Notre guide pour mettre en place un programme de divulgation des vulnérabilités décrit cette communication.

Questions fréquentes sur les correctifs Linux et Chrome

L’installation du dernier paquet de noyau suffit-elle à terminer la correction ?

Confirmez que le paquet contient la correction du fournisseur et que l’hôte l’exécute. Suivez la procédure de redémarrage ou de correctif à chaud prise en charge, puis consignez l’état actif.

Tous les serveurs Amazon Linux 2023 sont-ils corrigés ?

Le nom de la distribution ne permet aucune conclusion générale. Dans l’état des lieux du 30 octobre, le suivi d’Amazon indique des correctifs pour kernel6.12 et kernel6.18, tandis que la série kernel par défaut reste en attente. Comparez la famille de paquets de votre hôte à l’avis actuel d’Amazon.

Un numéro de noyau qui semble ancien prouve-t-il une vulnérabilité ?

Une distribution maintenue peut rétroporter un correctif. Utilisez la révision complète du paquet fournisseur et sa correspondance avec l’avis, puis vérifiez l’activation. Une comparaison avec les seules versions du projet Linux est insuffisante.

L’alerte signifie-t-elle que mon serveur a été compromis ?

L’alerte de vulnérabilité justifie une vérification de l’exposition et une correction. Affirmer une compromission nécessite des preuves distinctes provenant de votre environnement. Distinguez dans les dossiers le traitement du correctif et l’enquête sur l’incident.

L’évasion de Chrome prouve-t-elle qu’une page web peut prendre le contrôle de tous les Mac ?

La démonstration GPU publiée suppose une exécution préalable de code natif, et la description CVE de Google précise aussi qu’un processus de rendu doit déjà être compromis. Mettez à jour les navigateurs touchés et conservez ces prérequis lorsque vous décrivez les recherches.

Conservez le responsable du rapport et l’historique de vérification dans Kit

Pour transmettre le dossier, quelques éléments suffisent : un responsable désigné, l’avis applicable, l’action réalisée et les preuves examinées. L’équipe inspecte les hôtes et applique les correctifs ; le dossier permet à la prochaine personne chargée du traitement de comprendre la décision.

Le processus CSIRT de Kit permet d’attribuer un rapport, de conserver l’historique des attributions et des statuts, et de distinguer résolu de correctif vérifié. Les membres autorisés peuvent marquer comme vérifié le correctif d’un rapport résolu et ajouter une note facultative. Cette note peut renvoyer aux preuves relatives à l’hôte ; le changement de statut reste une confirmation humaine, pas un test automatisé du noyau.

Pour CVE-2026-98432, partez de la ligne actuelle du paquet fournisseur et allez jusqu’au noyau actif sur l’hôte. Pour CVE-2026-106378, vérifiez la version de Chrome en cours d’exécution après relance. Gardez les machines en attente visibles jusqu’à ce qu’elles remplissent leur condition de clôture. Si votre travail de divulgation nécessite un responsable et un historique de vérification partagé, vous pouvez essayer Kit.