La réponse courte
La CISA a ajouté le 18 septembre 2026 trois failles du noyau Linux activement exploitées à son catalogue KEV et donné aux agences fédérales jusqu'au 21 septembre pour corriger et rechercher toute compromission. La principale, CVE-2025-39682 (CVSS 9.8), est une faille dans le chemin de réception de Kernel TLS ; CVE-2026-53266 (CVSS 8.8) est une écriture hors limites dans le chemin SNAT d'ebtables ; et CVE-2025-39964 (CVSS 7.8) est une situation de compétition dans l'interface cryptographique AF_ALG. Red Hat indique que des exploits publics existent déjà. Le correctif est un noyau corrigé et un redémarrage.
Pour les équipes en France, l'essentiel est la portée. Le noyau Linux est le seul composant que partagent chaque VM cloud, nœud de conteneur et runner CI : une faille du noyau est donc une exposition à l'échelle du parc qui touche d'un coup toute votre plateforme cloud et DevOps — pas un serveur unique que vous pouvez discrètement reporter au mois prochain. Deux de ces failles sont des primitives d'élévation de privilèges et de corruption d'intégrité qui transforment un petit point d'appui en contrôle total de l'hôte.
Ce que la CISA a signalé
Le 18 septembre 2026, l'agence américaine de cybersécurité et de sécurité des infrastructures (CISA) a ajouté trois vulnérabilités du noyau Linux à son catalogue des vulnérabilités activement exploitées (KEV), en invoquant des preuves d'exploitation dans la nature. En vertu de la Binding Operational Directive 26-04, les agences fédérales civiles doivent corriger les trois avant le 21 septembre — et, fait inhabituel, la CISA a marqué chacune comme nécessitant une analyse forensique : les agences doivent enquêter activement sur les actifs exposés à la recherche de signes de compromission, sans considérer l'installation du correctif comme la fin du travail.
La plus grave est CVE-2025-39682, notée CVSS 9.8. Il s'agit d'une vérification incorrecte d'une condition exceptionnelle dans le chemin de réception de Kernel TLS (kTLS) : un cas limite où un enregistrement de longueur nulle récupéré depuis la rx_list interne contourne le traitement prévu du type d'enregistrement dans recvmsg(), entraînant une divulgation mémoire ou un déni de service. L'avis de Red Hat qualifie le problème de risque élevé et note que des exploits publics l'utilisant existent déjà. CVE-2026-53266 (CVSS 8.8) est une écriture hors limites dans le chemin Source NAT d'ebtables du pont netfilter, déclenchée lors des opérations de réécriture de l'adresse matérielle de l'expéditeur ARP, qui peut provoquer un comportement inattendu, un plantage ou une élévation locale de privilèges. CVE-2025-39964 (CVSS 7.8) est une situation de compétition permettant des écritures concurrentes sur le même socket AF_ALG — l'interface crypto-depuis-l'espace-utilisateur du noyau — qui peut faire planter le système ou corrompre le résultat d'une opération cryptographique, créant à la fois un risque de disponibilité et d'intégrité des données.
Ces trois failles ne sont pas liées entre elles et rien n'indique une chaîne d'attaque coordonnée unique ; ce sont trois faiblesses indépendantes du noyau qui se sont trouvées entrer au KEV le même jour. Les distributions ont réagi vite — Red Hat, par exemple, a actualisé ses avis le 19 septembre — et la correction est la même pour les trois : installer le noyau corrigé de votre distribution et redémarrer, ou appliquer un live-patch là où c'est pris en charge.
Pourquoi « local » ne veut pas dire « faible risque »
Deux de ces failles nécessitent un accès local, et la troisième affecte des utilisateurs locaux authentifiés, ce qui peut sembler rassurant — jusqu'à ce qu'on se souvienne de ce que « local » signifie dans un parc cloud-native. Un conteneur dont un attaquant s'est échappé, un point d'appui gagné via un exploit d'application web, une dépendance compromise s'exécutant dans une tâche CI ou un compte de service à faibles privilèges sont tous « locaux ». En pratique, l'intrusion initiale est rarement l'objectif ; c'est l'escalade de ce point d'appui vers root sur l'hôte qui l'est. L'écriture hors limites de CVE-2026-53266 est exactement ce type de primitive d'élévation de privilèges, et la capacité de CVE-2025-39964 à corrompre des résultats cryptographiques sape les garanties d'intégrité sur lesquelles reposent d'autres contrôles.
La faille kTLS soulève un autre signal. Kernel TLS déporte le chiffrement des flux réseau dans le noyau pour la performance, et il est utilisé par des services et proxys à haut débit. Un chemin accessible à distance qui aboutit à une divulgation mémoire ou à un plantage de ce sous-système est le genre de primitive que les attaquants intègrent à des campagnes plus vastes, ce qui explique probablement la note de 9.8 et la mention d'exploits publics existants. La leçon qui revient avec les CVE du noyau : la gravité tient à ce qu'un attaquant peut atteindre depuis là où il est déjà — et dans une infrastructure mutualisée, « déjà dans un conteneur sur un nœud partagé » est un point de départ courant, pas un point distant.
Ce que cela signifie pour les équipes logicielles en France
Premièrement, une CVE du noyau est un événement de flotte, pas un événement de serveur. Le noyau est l'unique composant que partagent vos VM, conteneurs et runners CI : l'exposition croît avec votre infrastructure, pas avec une seule application. Cela change la forme de la remédiation : vous ne corrigez pas un service, vous déployez des noyaux sur chaque hôte et nœud, reconstruisez les images de base de conteneurs qui héritent de ce noyau via l'hôte, et redémarrez ou appliquez un live-patch sans perdre de trafic de production. Les équipes dont la plateforme cloud et DevOps traite déjà les mises à jour du noyau comme un pipeline automatisé et testé absorberont cela en une journée ; celles qui corrigent les noyaux à la main découvriront combien d'hôtes elles avaient oubliés.
Deuxièmement, l'horloge de trois jours est un test d'inventaire et d'orchestration, pas de bonne volonté. Quand la CISA attache une analyse forensique à une entrée KEV, corriger seul ne suffit explicitement pas — vous devez pouvoir dire quels hôtes étaient affectés, quand ils ont été corrigés et si l'un d'eux a été touché auparavant. Cela exige des données d'actifs à jour, une journalisation centralisée et la capacité de planifier un redémarrage hors bande sur tout le parc à court préavis. Ce sont des capacités que l'on construit à l'avance ; on ne peut pas les improviser dans une fenêtre de 72 heures.
Troisièmement, pour les équipes réglementées, c'est un événement de conformité et de notification. Une faille du noyau permettant d'obtenir root, avec exploitation confirmée, relève directement dans l'UE des attentes de NIS2 et de DORA en matière de sécurité du traitement et de remédiation rapide et documentée — et en France, du cadre transposé (obligations pour les entités essentielles et importantes, notification au CERT-FR) ainsi que, pour les données personnelles, des exigences de la CNIL au titre du RGPD en cas de violation. Pouvoir produire le calendrier de correction, la liste des actifs affectés et les conclusions de la triage est la preuve que les auditeurs et les régulateurs demandent en premier — et bien plus facile à générer quand la gestion des correctifs et la journalisation sont déjà conçues plutôt que reconstituées après coup.
Que faire maintenant
- Inventoriez le parc. Recensez chaque hôte Linux, nœud de cluster et runner CI et cartographiez les versions de noyau en cours. Les machines absentes de votre inventaire sont celles qui restent non corrigées après l'échéance.
- Corrigez et redémarrez. Installez le noyau corrigé de votre distribution et redémarrez, ou appliquez un live-patch là où votre plateforme le prend en charge. Priorisez les nœuds mutualisés, les hôtes exposés à Internet et les runners CI qui exécutent du code non fiable.
- Reconstruisez les images de conteneurs. Les conteneurs héritent du noyau de l'hôte, mais les images de base et de nœud doivent tout de même être rafraîchies là où elles figent des composants couplés au noyau ; reconstruisez et redéployez pour que rien ne s'exécute sur une ancienne image de nœud.
- Appliquez des mesures provisoires si vous devez attendre. Là où un redémarrage immédiat est impossible, réduisez l'exposition : désactivez kTLS s'il est inutilisé, supprimez les règles SNAT ebtables de réécriture ARP, restreignez la capacité
CAP_NET_ADMINet bloquez le moduleaf_algaprès évaluation de l'impact. Ce sont des palliatifs, pas des correctifs. - Chassez, puis testez. Suivez l'exigence de triage de la CISA — examinez les journaux des hôtes exposés à la recherche de traces d'exploitation antérieure, pas seulement de l'état du correctif — et ajoutez les chemins de noyau et d'élévation de privilèges au périmètre de votre prochain test d'intrusion pour sonder délibérément l'escalade depuis un point d'appui.
Foire aux questions
Quelles failles du noyau Linux la CISA a-t-elle ajoutées au catalogue KEV ?
Le 18 septembre 2026, la CISA en a ajouté trois : CVE-2025-39682, une faille CVSS 9.8 de vérification de condition incorrecte dans le chemin de réception de Kernel TLS (kTLS) ; CVE-2026-53266, une écriture hors limites CVSS 8.8 dans le chemin SNAT ARP d'ebtables du pont netfilter ; et CVE-2025-39964, une situation de compétition CVSS 7.8 dans l'interface de socket cryptographique AF_ALG. Les trois sont signalées comme activement exploitées.
Quelle est l'échéance du correctif ?
En vertu de la Binding Operational Directive 26-04, les agences fédérales civiles américaines doivent corriger les trois avant le 21 septembre 2026. La CISA a aussi marqué les failles comme nécessitant une analyse forensique, de sorte que les agences doivent enquêter sur les actifs exposés à la recherche de compromission plutôt que de traiter le correctif comme la seule étape. L'échéance lie les agences fédérales, mais l'inscription au KEV est un signal fort que toute organisation devrait traiter ces failles comme urgentes.
Sont-ce des failles locales, et cela les rend-il moins graves ?
Deux nécessitent un accès local et une affecte des utilisateurs locaux authentifiés, mais « local » est un seuil bas dans l'infrastructure moderne. Un conteneur compromis, un point d'appui issu d'un exploit d'application web ou une tâche CI à faibles privilèges comptent tous comme locaux. Ces failles fournissent des primitives d'élévation de privilèges, de déni de service et de corruption d'intégrité qui s'enchaînent avec un accès initial pour prendre le contrôle d'un hôte, s'échapper d'un conteneur ou faire planter un nœud.
Comment corriger si un redémarrage immédiat est impossible ?
Le correctif complet est un noyau corrigé et un redémarrage, ou un live-patch là où votre distribution le prend en charge. Comme mesures temporaires, les recommandations suggèrent de désactiver kTLS s'il est inutilisé, de supprimer les règles SNAT ebtables de réécriture ARP, de restreindre la capacité CAP_NET_ADMIN et d'empêcher le chargement du module af_alg après évaluation de l'impact opérationnel. Ces mesures réduisent l'exposition mais ne remplacent pas la mise à jour du noyau.
Qu'est-ce que cela signifie pour les charges cloud et conteneurs ?
Le noyau est le socle commun de presque chaque VM cloud, conteneur et runner CI ; une faille du noyau est donc une exposition à l'échelle de toute la flotte. Les nœuds mutualisés partagent un seul noyau entre les charges, et les runners CI exécutent du code non fiable. Corrigez les noyaux des hôtes et des nœuds, reconstruisez et redéployez les images de base, et priorisez d'abord les hôtes exposés à Internet et mutualisés.
Sources
The Hacker News — CISA Flags Three Linux Kernel Vulnerabilities Exploited in the Wild
CISA — Known Exploited Vulnerabilities Catalog
Cyber Security News — CISA Warns of Linux Kernel Vulnerabilities Actively Exploited in Attacks