Noyau Linux : 3 CVE exploitées entrent au catalogue KEV

Le 18 septembre 2026, la Cybersecurity and Infrastructure Security Agency, CISA (1), publie deux alertes distinctes qui ajoutent trois CVE (2) au catalogue Known Exploited Vulnerabilities, KEV (3). La première inscrit la CVE-2025-39682 ; la seconde inscrit la CVE-2025-39964 et la CVE-2026-53266. Les trois entrées portent la même date d’ajout, la même échéance de correction au 21 septembre 2026 et la même mention : triage forensique requis au titre de la directive BOD (4) 26-04. Le champ relatif à l’usage dans des campagnes de ransomware est renseigné « inconnu » pour les trois.

Les trois vulnérabilités touchent des sous-systèmes distincts du noyau : la réception TLS (5) en noyau, dite kTLS, pour la CVE-2025-39682 ; la cible SNAT (6) d’ebtables sur les ponts réseau pour la CVE-2026-53266 ; l’interface AF_ALG, qui expose les algorithmes cryptographiques du noyau aux processus utilisateur, pour la CVE-2025-39964. Aucune n’est un zero-day : le CNA (7) du noyau Linux les a publiées respectivement le 5 septembre 2025, le 25 juin 2026 et le 13 octobre 2025, avec les correctifs correspondants dans les branches stables. Debian et Ubuntu ont diffusé des correctifs pour chacune des trois. Chez Red Hat, l’instantané de données repris par OpenCVE donnait RHEL 9 et RHEL 10 comme concernées par la CVE-2025-39682 et la CVE-2026-53266, et un correctif différé pour la CVE-2025-39964 de RHEL 7 à RHEL 10 ; la date de cet instantané n’est pas connue et l’état courant se vérifie sur la page de l’éditeur.

La CISA n’a publié aucun détail sur les exploitations observées ni sur un éventuel enchaînement des trois failles. Red Hat a mis à jour ses trois avis le 19 septembre à 2 h UTC pour prendre en compte l’exploitation active, d’après The Hacker News et Secure in Seconds ; la formulation rapportée qualifie la CVE-2025-39682 de risque élevé avec des codes d’exploitation publics connus. Cette mention n’apparaît pas dans la version des pages Red Hat relevée pour cet article.

La CISA regroupe les trois entrées sous l’étiquette « Linux Kernel », mais elles n’ont ni le même vecteur, ni les mêmes conditions préalables, ni le même âge. Le tableau reprend les valeurs publiées par le CNA du noyau, relevées sur les fiches d’origine : catégorie CWE (8), versions d’introduction et de correction, condition d’accès à la faille.

Fig. 1 : les trois CVE, leur catégorie CWE, les versions d’introduction et de correction publiées par le CNA du noyau, et la condition d’accès à la faille.

CVE-2025-39682, la réception kTLS

Le noyau peut terminer lui-même les sessions TLS d’un socket TCP lorsque l’application lui attache le protocole de couche supérieure TLS ; c’est le mode kTLS, utilisé par OpenSSL lorsqu’il est compilé avec cette option, par NFS (9) avec TLS et par les transports SMB (10) et RPC (11) avec TLS via le mécanisme net/handshake du noyau. Chaque appel recvmsg() doit traiter soit une suite d’enregistrements de type DATA, soit un seul enregistrement d’un autre type. Le défaut tient à un cas limite : lorsque le premier enregistrement traité vient de la file rx_list et qu’il est de longueur nulle, le contrôle de type est contourné et les enregistrements suivants sont traités avec des hypothèses de zero-copy et de mise en file qui ne sont plus valides.

La justification publiée par le CNA avec sa notation décrit la séquence déclenchante : trois enregistrements consécutifs envoyés par le pair distant, un enregistrement DATA, un enregistrement de longueur nulle d’un autre type, puis un enregistrement DATA. L’effet est déterministe, sans condition de concurrence ni dépendance à la disposition mémoire, et le test de non-régression ajouté avec le correctif le reproduit en une passe. Les conséquences décrites sont une copie de mémoire noyau libérée vers l’espace utilisateur, une écriture après libération sur la structure d’ancrage du flux, une double libération à la fermeture du socket et un plantage du noyau. Le mode zero-copy est actif par défaut en TLS 1.2, ce qui ne demande aucune option particulière côté victime.

Le correctif initialise et vérifie le type de contenu à chaque appel et interrompt le traitement dès qu’un enregistrement non DATA suit un enregistrement DATA. Annoncé le 5 septembre 2025 avec les correctifs des branches 6.1, 6.6, 6.12 et 6.16, il a été diffusé par Debian dans les avis DSA-6008-1 et DSA-6009-1 et par Ubuntu dans la série USN-7833 et suivantes. Red Hat précise que le défaut n’est atteignable que si le protocole kTLS est attaché à un socket, et propose comme mesure de contournement d’interdire le chargement du module tls.

CVE-2026-53266, la réécriture ARP de la cible SNAT d’ebtables

Sur un pont réseau Linux, ebtables permet de réécrire l’adresse MAC (12) source des trames par la cible SNAT. Cette réécriture de l’en-tête Ethernet est protégée par un appel à skb_ensure_writable(). L’option de la même cible qui réécrit aussi l’adresse matérielle de l’émetteur dans les messages ARP (13) ne l’est pas : elle écrit par skb_store_bits() à un décalage relatif au début de la charge utile, alors que la lecture préalable de l’en-tête ARP par skb_header_pointer() ne garantit pas que la zone visée soit inscriptible. Si cette zone se trouve dans un fragment non linéaire du tampon de socket adossé à une page de fichier importée par splice(), les six octets de la nouvelle adresse MAC sont écrits directement dans la page du cache de fichiers.

La notation du CNA retient un vecteur local : l’attaquant doit contrôler la configuration du pont et des règles ebtables, et disposer lui-même les fragments partagés ; du trafic ARP distant ne suffit pas. La capacité requise, CAP_NET_ADMIN, est atteignable depuis un espace de noms utilisateur et réseau sans être root dans l’espace de noms initial, ce qui explique le niveau de privilèges bas retenu et le changement de périmètre : la corruption touche des pages de fichiers hors de la frontière du sous-système réseau.

Le correctif rend la zone de l’adresse matérielle inscriptible avant la lecture de l’en-tête ARP et avant l’appel à skb_store_bits(). Il date du 25 juin 2026 ; Debian l’a diffusé dans les avis DLA-4664-1, DLA-4665-1 et DLA-4671-1 en juillet 2026, Ubuntu dans la série USN-8726 et suivantes. La fiche du CNA ne liste aucune version corrigée pour les branches 5.4, 5.8 et 5.9, où le commit d’origine avait été rétroporté. Le catalogue KEV porte pour cette entrée, comme pour la CVE-2025-39682, la mention que les produits concernés peuvent être en fin de vie ou de support. Red Hat propose comme mesure de contournement de retirer la réécriture ARP des règles SNAT, ou de retirer les règles SNAT qui s’appliquent au trafic ARP sur les ponts.

CVE-2025-39964, les écritures concurrentes sur AF_ALG

AF_ALG est la famille de sockets par laquelle un processus utilisateur soumet des opérations à l’API (14) cryptographique du noyau. Deux appels sendmsg() concurrents sur le même socket entrelacent leurs données de façon imprévisible et laissent l’état interne du socket incohérent. Le correctif ajoute un champ ctx->write qui réserve l’écriture à un seul appelant à la fois. Il date du 13 octobre 2025 ; Debian l’a diffusé dans l’avis DSA-6053-1 et les avis DLA-4379-1 et DLA-4404-1, Ubuntu dans la série USN-7907 et suivantes.

La description d’origine ne parle que d’entrelacement et d’incohérence. La justification de notation ajoutée par le CNA en juillet 2026 est plus précise : l’attaquant contrôle les deux côtés de la course, avec deux threads sur un socket qu’il possède, et peut bloquer le premier écrivain de façon déterministe en dimensionnant le tampon d’émission. Les appels socket(), bind() et de définition de clé n’exigent aucune capacité, les modules nécessaires sont chargés à la demande, et un utilisateur sans privilège, y compris dans un conteneur, y accède. La course produit une entrée de liste de dispersion hors limites, exploitée ensuite pour lire de la mémoire noyau et pour y écrire des données choisies, ce que le CNA qualifie de primitive adaptée à une élévation de privilèges. Red Hat résume l’impact en déni de service et corruption des résultats cryptographiques ; la fiche KEV reprend la description d’origine sans qualifier l’impact ; l’enrichissement SSVC (15) de la CISA retient un impact technique total. Red Hat propose comme mesure de contournement d’interdire le chargement du module af_alg.

Chaque CVE porte jusqu’à trois notations CVSS (16) 3.1 : celle du CNA du noyau, publiée sur cve.org avec une justification par métrique ; celle de la NVD (17), qui a produit sa propre notation pour deux des trois fiches ; celle de Red Hat, calculée pour ses propres produits. Les écarts portent sur le vecteur d’attaque, pas seulement sur la gravité. Les pages Red Hat affichent les trois valeurs côte à côte, ce qui permet de les relever au même endroit.

Fig. 2 : notations CVSS 3.1 publiées par les trois sources pour chaque CVE, et valeurs de décision SSVC publiées par la CISA. Valeurs relevées le 20 septembre 2026.

Pour la CVE-2025-39682, le CNA et Red Hat retiennent un vecteur réseau, l’attaquant étant le pair TLS ; la NVD retient un vecteur local avec privilèges bas. Les trois lectures reposent sur le même texte de fiche. Red Hat abaisse l’impact en confidentialité et en intégrité au niveau faible et relève la complexité d’attaque, ce qui donne 7,0 là où le CNA obtient 9,8. Pour la CVE-2026-53266, la situation s’inverse : le CNA retient un vecteur local et un changement de périmètre, Red Hat un vecteur réseau à complexité élevée. Pour la CVE-2025-39964, la NVD et Red Hat ne retiennent qu’un impact en disponibilité, le CNA un impact complet sur les trois critères.

Ces notations ont bougé dans le temps. D’après l’historique conservé par OpenCVE, le CNA du noyau a relevé le 30 juillet 2026 la CVE-2025-39682 de 7,1 à 9,8 et la CVE-2025-39964 de 3,3 à 7,8, en publiant à cette occasion la justification métrique par métrique reprise plus haut. Cette dernière CVE avait été abaissée de 5,5 à 3,3 en février 2026. Les scores EPSS (18) restent bas à la date de rédaction : 1,2 % pour la CVE-2025-39682, 0,79 % pour la CVE-2025-39964, 0,28 % pour la CVE-2026-53266, alors que les trois sont exploitées.

La BOD 26-04, publiée le 10 juin 2026, remplace la BOD 22-01 de novembre 2021 et la BOD 19-02. Elle s’applique aux agences civiles fédérales américaines, dites FCEB (19). Le délai uniforme de correction des entrées KEV disparaît au profit d’un tableau de seize combinaisons de quatre variables : exposition publique de l’actif, présence au catalogue KEV, automatisation de l’exploitation, impact technique total ou partiel. Les délais vont de trois jours calendaires à la correction lors de la prochaine mise à niveau du système. Les combinaisons les plus courtes ajoutent une obligation : le triage forensique de l’actif, pour établir si le système a été compromis avant l’application du correctif.

Le guide d’application précise que la CISA calcule elle-même l’échéance inscrite au catalogue KEV en appliquant ce tableau aux données dont elle dispose, exposition publique comprise, et que l’échéance du catalogue prime. C’est ce calcul qui donne le 21 septembre 2026 pour les trois entrées, soit trois jours à compter du 18 septembre. Deux des trois CVE ne sont pas automatisables au sens de la CISA ; l’exploitation active et l’impact total ont suffi à déclencher la tranche la plus courte, ce qui correspond à la lecture du tableau publiée par Tenable, selon laquelle la présence au catalogue KEV et l’impact total suffisent à cette tranche. Le guide indique aussi que la CISA ajoute au catalogue les indicateurs de compromission dont elle dispose ; à la date de rédaction, les alertes n’en publient aucun et les sources consultées n’en rapportent aucun.

Le calendrier de la directive laisse aux agences jusqu’au 7 décembre 2026 pour appliquer intégralement les délais du tableau, selon la synthèse publiée par le programme FedRAMP, ce qui n’empêche pas l’échéance du 21 septembre de figurer au catalogue. Pour les organisations hors du champ de la directive, cette échéance n’a pas de valeur contraignante ; elle indique le niveau de priorité que la CISA attribue à ces trois failles au regard de ce qu’elle observe. Dans le texte accompagnant la directive, la CISA citait le rapport DBIR 2026 de Verizon : 26 % des vulnérabilités du catalogue KEV entièrement corrigées en 2025, contre 38 % l’année précédente.

Les faits d’ajout au catalogue et les données techniques viennent de sources primaires. Les circonstances de l’exploitation ne sont documentées par aucune d’entre elles.

Fig. 3 : statut de chaque élément repris dans l’article selon le nombre et la nature des sources qui l’établissent.

Dans les trois jours

• Relever le noyau en cours d’exécution sur chaque hôte avec uname -r, et non la version portée par l’inventaire ou le manifeste de déploiement. Comparer le résultat aux avis de la distribution, qui numérote ses noyaux à sa façon : les versions amont du tableau de la section 2 ne se lisent pas directement dans une version Debian, Ubuntu, Red Hat ou SUSE.
• Ordonner par ce que l’hôte peut atteindre : hyperviseurs, hôtes de conteneurs, exécuteurs d’intégration continue porteurs de secrets de déploiement, bastions, avant les postes de travail.
• Planifier le redémarrage en même temps que la mise à jour : les trois correctifs sont des changements de code du noyau, et les mesures de contournement proposées par Red Hat retirent le module ou l’option en cause plutôt qu’elles ne ferment la faille à fonction constante. Les mécanismes de correction à chaud des distributions s’appliquent lorsqu’ils sont en place.

Par CVE

• CVE-2025-39682 : identifier les hôtes qui terminent du TLS en noyau. Le module tls chargé et des compteurs non nuls dans /proc/net/tls_stat signalent des sessions kTLS ; les candidats sont les serveurs web configurés avec kTLS, les serveurs et clients NFS avec TLS, les services qui utilisent net/handshake. À défaut de correctif, interdire le chargement du module tls comme le propose Red Hat, au prix de la perte de la fonction.
• CVE-2026-53266 : lister les règles ebtables de la table nat sur les hôtes portant des ponts, avec ebtables -t nat -L ou son équivalent nftables. La faille exige une cible SNAT avec l’option --snat-arp ; retirer cette option ou interdire le chargement du module ebt_snat ferme le chemin décrit. La capacité CAP_NET_ADMIN étant atteignable depuis un espace de noms utilisateur d’après le CNA, restreindre la création d’espaces de noms utilisateur sans privilège réduit la surface sur les hôtes qui n’en ont pas besoin ; cette restriction se teste, certains environnements de conteneurs en dépendent.
• CVE-2025-39964 : considérer comme exposé tout hôte non corrigé où un utilisateur sans privilège peut exécuter du code, conteneurs compris. Interdire le chargement du module af_alg ferme le chemin, mais prive les applications qui utilisent l’API cryptographique du noyau par cette interface, par exemple libkcapi ou le moteur afalg d’OpenSSL. Ce contournement se vérifie avant déploiement.

Au-delà du correctif

• Conduire le triage forensique sur les hôtes qui ont été exposés avant correction, même hors du champ de la directive. En l’absence d’indicateur publié, le triage repose sur des signaux génériques : les plantages et messages d’erreur du noyau dans les journaux, les modules chargés sans raison connue, la création d’espaces de noms ou de ponts par des comptes qui n’en ont pas l’usage, et les connexions kTLS vers des pairs non attendus.
• Étendre le recensement aux équipements industriels et embarqués : Siemens liste le SIMATIC CN 4100 avant la version V5.0 pour la CVE-2025-39682, et les CPU SIMATIC S7-1500 1518-4 et 1518F-4 PN/DP MFP ainsi que leur variante SIPLUS à partir de la version V3.1.6 pour la CVE-2025-39964.
• Traiter le délai de trois jours comme un indicateur de priorité et non comme une obligation, sauf pour les entités soumises à la directive ; le modèle à quatre variables de la BOD 26-04 se transpose à toute organisation qui sait dire lesquels de ses actifs sont exposés.

1. CISA (1) : Cybersecurity and Infrastructure Security Agency, agence américaine de cybersécurité et de sécurité des infrastructures.
2. CVE (2) : Common Vulnerabilities and Exposures, identifiant public unique d’une vulnérabilité.
3. KEV (3) : Known Exploited Vulnerabilities, catalogue tenu par la CISA des vulnérabilités pour lesquelles une exploitation a été constatée.
4. BOD (4) : Binding Operational Directive, directive contraignante de la CISA applicable aux agences civiles fédérales américaines.
5. TLS (5) : Transport Layer Security, protocole de chiffrement des communications ; kTLS désigne sa mise en œuvre dans le noyau Linux.
6. SNAT (6) : Source Network Address Translation, réécriture de l’adresse source ; dans ebtables, la cible qui réécrit l’adresse MAC source des trames.
7. CNA (7) : CVE Numbering Authority, entité habilitée à attribuer des identifiants CVE dans son périmètre, ici l’équipe CVE du noyau Linux.
8. CWE (8) : Common Weakness Enumeration, classification des types de faiblesses logicielles.
9. NFS (9) : Network File System, protocole de partage de fichiers, dont les versions récentes peuvent être transportées sur TLS.
10. SMB (10) : Server Message Block, protocole de partage de fichiers et d’impression.
11. RPC (11) : Remote Procedure Call, mécanisme d’appel de procédure entre systèmes.
12. MAC (12) : Media Access Control, adresse matérielle d’une interface réseau.
13. ARP (13) : Address Resolution Protocol, protocole d’association entre adresses IP et adresses MAC sur un réseau local.
14. API (14) : Application Programming Interface, interface d’accès programmatique à un service.
15. SSVC (15) : Stakeholder-Specific Vulnerability Categorization, méthode de décision utilisée par la CISA, dont les valeurs d’exploitation, d’automatisation et d’impact technique alimentent la BOD 26-04.
16. CVSS (16) : Common Vulnerability Scoring System, cadre de notation standardisé de la gravité d’une vulnérabilité.
17. NVD (17) : National Vulnerability Database, base américaine de vulnérabilités tenue par le NIST, qui publie sa propre notation.
18. EPSS (18) : Exploit Prediction Scoring System, estimation de la probabilité d’exploitation d’une vulnérabilité dans les trente jours.
19. FCEB (19) : Federal Civilian Executive Branch, agences civiles fédérales américaines soumises aux directives de la CISA.

1. CISA, CISA Adds One Known Exploited Vulnerability to Catalog, 18 septembre 2026. cisa.gov
2. CISA, CISA Adds Two Known Exploited Vulnerabilities to Catalog, 18 septembre 2026. cisa.gov
3. CISA, Known Exploited Vulnerabilities Catalog, consulté le 20 septembre 2026. cisa.gov
4. CISA, BOD 26-04 Prioritizing Security Updates Based on Risk, 10 juin 2026. cisa.gov
5. CISA, BOD 26-04 Implementation Guidance for Prioritizing Security Updates Based on Risk, 10 juin 2026. cisa.gov
6. Équipe CVE du noyau Linux, annonce de la CVE-2025-39682 sur linux-cve-announce, 5 septembre 2025. lore.kernel.org
7. Équipe CVE du noyau Linux, annonce de la CVE-2025-39964 sur linux-cve-announce, 13 octobre 2025. lore.kernel.org
8. Équipe CVE du noyau Linux, annonce de la CVE-2026-53266 sur linux-cve-announce, 25 juin 2026. lore.kernel.org
9. CVE Program, fiches CVE-2025-39682, CVE-2025-39964 et CVE-2026-53266, notation du CNA avec justification par métrique et enrichissement CISA ADP, consultées le 20 septembre 2026. cve.org
10. OpenCVE, fiches des trois CVE avec historique des changements de notation, consultées le 20 septembre 2026. opencve.io
11. Red Hat, CVE-2025-39682, consulté le 20 septembre 2026. access.redhat.com
12. Red Hat, CVE-2026-53266, consulté le 20 septembre 2026. access.redhat.com
13. Red Hat, CVE-2025-39964, consulté le 20 septembre 2026. access.redhat.com
14. Siemens ProductCERT, avis SSA-032379 (SIMATIC CN 4100) et SSA-019113 (SIMATIC S7-1500). cert-portal.siemens.com
15. The Hacker News, CISA Flags Three Linux Kernel Vulnerabilities Exploited in the Wild, 19 septembre 2026. thehackernews.com
16. Secure in Seconds, Three Linux kernel bugs hit CISA’s exploited list the same day four public root exploits landed, 20 septembre 2026. secureinseconds.com
17. Tenable, CISA BOD 26-04: Frequently asked questions about the new risk-based patching directive, 11 juin 2026. tenable.com
18. FedRAMP, FedRAMP Response to CISA BOD 26-04, 16 juin 2026. fedramp.gov
19. exploit-intel.com, fiche CVE-2026-53266, analyse du dépôt référencé comme PoC, consultée le 20 septembre 2026. exploit-intel.com