Trois failles critiques du noyau Linux viennent de rejoindre le catalogue des vulnérabilités activement exploitées de la CISA. L’agence américaine de cybersécurité les a ajoutées le 18 septembre 2026, un vendredi, et a donné aux agences fédérales jusqu’au dimanche 21 septembre pour appliquer un correctif. Soit 72 heures, montre en main.
Les trois CVE touchent des sous-systèmes très différents du noyau : le chiffrement TLS accéléré côté noyau (kTLS), le filtrage réseau par pont (ebtables) et l’interface qui expose la cryptographie du noyau aux applications (AF_ALG). Cette dispersion n’a rien d’anodin. Elle signale que plusieurs points d’entrée du noyau Linux font l’objet d’un intérêt actif au même moment, pas d’une seule faille isolée.
Pour les équipes techniques en France et ailleurs en Europe, la directive fédérale américaine BOD 26-04 ne s’applique pas directement. Mais le signal qu’elle envoie traverse l’Atlantique sans effort. Le catalogue KEV de la CISA sert de référence de facto pour prioriser les correctifs bien au-delà des frontières américaines, et les trois failles concernent des composants qui tournent, souvent sans qu’on y pense, sur une bonne partie de l’infrastructure web européenne.
Trois failles, un même catalogue, trois sous-systèmes distincts
Le 18 septembre 2026, la CISA a inscrit CVE-2025-39682, CVE-2026-53266 et CVE-2025-39964 à son catalogue Known Exploited Vulnerabilities. Les trois partagent un point commun : une preuve d’exploitation active confirmée, pas seulement théorique. C’est précisément ce critère qui distingue une entrée KEV d’un simple CVE publié dans la nature.
Red Hat a mis à jour ses propres avis pour les trois références et confirme que des exploits publics circulent déjà. Ce n’est donc pas une alerte préventive. Des attaquants disposent, pour au moins l’une des trois failles, d’un code fonctionnel.
La dispersion technique frappe les analystes qui suivent ce dossier. Un attaquant qui viserait le noyau Linux pourrait choisir d’attaquer la réception TLS, le filtrage de paquets ou l’API cryptographique, trois portes d’entrée qui n’ont presque rien en commun sur le plan technique. Que les trois se retrouvent exploitées la même semaine suggère un intérêt soutenu pour le noyau dans son ensemble, plutôt qu’une faille isolée qui aurait attiré l’attention par hasard.
CVE-2025-39682, la faille kTLS qui piège les enregistrements vides
kTLS, ou kernel TLS, est une optimisation qui délègue au noyau Linux le déchiffrement des flux TLS entrants. Une application active la fonctionnalité en appelant setsockopt() avec l’option TCP_ULP réglée sur “tls”. Le noyau prend alors la main sur le déchiffrement et livre directement le texte en clair à l’application, sans passer par une bibliothèque comme OpenSSL en espace utilisateur. Nginx, certaines versions d’OpenSSL équipées d’un fournisseur ktls et de nombreux serveurs à fort débit s’appuient sur ce mécanisme pour réduire la charge CPU liée au TLS.
Le défaut réside dans la fonction tls_sw_recvmsg(), dans le fichier net/tls/tls_sw.c. Elle est censée traiter, en un seul appel, soit une séquence d’enregistrements de données contigus, soit un seul enregistrement non-data comme une alerte ou un message de handshake. Le cas limite oublié survient quand le premier enregistrement tiré de la file rx_list a une longueur nulle : la détection de changement de type peut alors être contournée. En TLS 1.3, où le type réel de l’enregistrement n’est connu qu’après déchiffrement, un enregistrement suivant d’un type différent peut ensuite être traité sous de mauvaises hypothèses.
Red Hat décrit le mécanisme précis dans son avis officiel. En mode zero-copy, le noyau place le tampon anchor (strp->anchor) dans rx_list, une opération normalement interdite dans ce mode. Cela corrompt le compteur de références de l’anchor et provoque un use-after-free à la fermeture du socket, au moment où tls_sw_release_resources_rx parcourt une mémoire déjà libérée.
Des chercheurs de STAR Labs, basés à Singapour, ont découvert la faille. Leur preuve de concept, qui déclenche un use-after-free confirmé par l’outil KASAN au niveau de kfree_skb_list_reason, circule déjà publiquement. Le score CVSS diverge fortement selon la source : Red Hat le note à 7,0, contre 9,8 chez le NVD et chez cve.org. L’écart tient surtout à l’évaluation de l’impact sur la confidentialité et l’intégrité, jugé faible par Red Hat et élevé par les deux autres organismes.
Red Hat a publié des correctifs pour RHEL 9 (kernel-0:5.14.0-570.49.1.el9_6) et RHEL 10, sous les références RHSA-2025:16880 et RHSA-2025:16904. Aucun contournement par simple configuration n’existe. La seule mitigation possible consiste à empêcher le chargement du module tls, ce qui désactive kTLS dans son ensemble.
CVE-2026-53266, un paquet ARP qui corrompt la mémoire du noyau
La deuxième faille touche le sous-système bridge netfilter, plus précisément la cible ebt_snat, qui permet aux règles ebtables de réécrire l’adresse MAC source dans des trames Ethernet pontées. Le bug tient à l’absence de vérification d’inscriptibilité avant une écriture en mémoire.
Quand la cible ebt_snat traite un paquet ARP, elle utilise skb_header_pointer() pour lire l’en-tête, une fonction qui ne garantit qu’un accès en lecture. Un appel ultérieur à skb_store_bits() écrase ensuite l’adresse MAC de l’expéditeur à un décalage donné, sans vérifier que cette zone mémoire est accessible en écriture. Quand la plage d’adresses matérielles de l’expéditeur ARP se trouve dans un fragment de tampon non linéaire, adossé à une page importée par splice, l’écriture se produit directement dans cette page sans contrôle du noyau. Résultat : une écriture hors limites capable de corrompre la mémoire d’objets totalement indépendants.
L’impact documenté est une élévation de privilèges locale via corruption mémoire. Un attaquant a besoin de la capacité CAP_NET_ADMIN, ou d’un accès équivalent lui permettant de charger des règles netfilter, ce qui limite le scénario aux environnements où cette capacité circule déjà (conteneurs mal isolés, environnements multi-tenant, machines virtuelles avec accès réseau étendu).
Le CVE a été publié le 25 juin 2026. Red Hat le note à 7,5, cve.org à 8,8. Le correctif ajoute un appel à skb_ensure_writable() avant l’écriture de l’adresse matérielle ARP. Red Hat a publié trois avis liés : RHSA-2026:36645, RHSA-2026:39082 et RHSA-2026:39083. Contrairement à la faille kTLS, un contournement existe en théorie (désactiver les règles ebtables SNAT), mais il reste rarement viable dans les architectures de production qui en dépendent pour le renattage d’adresses.
CVE-2025-39964, la course critique dans l’API cryptographique AF_ALG
Troisième faille du lot, et sans doute la plus ancienne dans son exposition. AF_ALG est l’interface du noyau Linux qui expose les opérations cryptographiques à l’espace utilisateur via des sockets. Des applications s’en servent pour déléguer du chiffrement, du hachage ou de la génération de nombres aléatoires directement au noyau plutôt qu’à une bibliothèque logicielle.
Le défaut est une condition de concurrence critique. L’interface autorisait deux écritures simultanées sur le même socket. Les charges utiles envoyées par des threads distincts peuvent alors s’entrelacer de façon imprévisible dans la file de traitement cryptographique du noyau, laissant le contexte du socket dans un état incohérent. Les conséquences vont d’une sortie cryptographique corrompue, en soi dangereuse pour tout système qui s’appuie sur le chiffrement médié par le noyau, jusqu’au panic du noyau dans les cas les plus sévères.
La faille a été publiée le 13 octobre 2025 et affiche l’écart de notation le plus spectaculaire des trois. Le NVD la note à 5,5 (moyen), Red Hat à 7,3, cve.org, l’autorité de nommage du CVE, à 7,8 (élevé). Le NVD retient un impact nul sur la confidentialité et l’intégrité, quand Red Hat et cve.org les jugent respectivement faible-à-élevé et élevé. La CISA recommande d’utiliser l’inscription au catalogue KEV comme signal faisant autorité sur l’exploitation active, indépendamment du score retenu.
Autre particularité : la plage de versions concernées démarre au noyau 2.6.38, sorti en 2011, et s’étend jusqu’à 6.16.9 et la version de développement 6.17-rc6. Une fenêtre d’exposition nettement plus large que celle des deux autres CVE, ce qui en fait potentiellement la surface d’attaque la plus étendue du trio malgré un score parfois jugé modéré. La mitigation recommandée par Red Hat consiste à empêcher le chargement du module af_alg, au prix de la désactivation de toute cryptographie médiée par le noyau pour les applications qui en dépendent.
Comparer les trois failles en un coup d’œil
Le tableau ci-dessous résume les caractéristiques techniques des trois CVE, avec les scores CVSS tels que publiés directement par Red Hat, le NVD et cve.org sur leurs pages officielles. Les écarts de notation, parfois supérieurs à quatre points sur dix, montrent à quel point l’évaluation de la gravité d’une faille noyau dépend du contexte d’usage retenu par chaque organisme.
| CVE | Composant / sous-système | CVSS Red Hat | CVSS NVD | CVSS cve.org | Publication initiale |
|---|---|---|---|---|---|
| CVE-2025-39682 | kTLS (net/tls/tls_sw.c) | 7,0 | 9,8 | 9,8 | 5 septembre 2025 |
| CVE-2026-53266 | Netfilter ebtables (ebt_snat) | 7,5 | Non noté | 8,8 | 25 juin 2026 |
| CVE-2025-39964 | AF_ALG (API crypto noyau) | 7,3 | 5,5 | 7,8 | 13 octobre 2025 |
Malgré ces divergences, un point fait consensus. Les trois failles bénéficient d’une exploitation active confirmée, ce qui justifie à lui seul leur inscription au catalogue KEV, indépendamment du chiffre affiché sur chaque page vendeur.
BOD 26-04, la nouvelle doctrine de patch de la CISA
Le délai de 72 heures découle directement de la directive opérationnelle contraignante BOD 26-04, intitulée “Prioritizing Security Updates Based on Risk”, publiée par la CISA le 10 juin 2026. Le texte remplace deux directives plus anciennes, BOD 22-01 (2021) et BOD 19-02 (2019), qui imposaient des délais fixes calculés uniquement à partir du score CVSS, sans distinction de contexte d’exposition.
BOD 26-04 introduit à la place un modèle à quatre variables. L’actif est-il exposé publiquement sur internet, la faille figure-t-elle au catalogue KEV, l’exploitation est-elle automatisable, et quel est l’impact technique potentiel en cas de compromission. Les vulnérabilités qui obtiennent le score maximal sur les quatre critères basculent dans le palier de remédiation le plus agressif : trois jours calendaires, assortis d’une obligation nouvelle de triage forensique qui impose aux agences de déterminer si l’actif était déjà compromis avant l’application du correctif.
Les trois CVE ajoutées le 18 septembre entrent toutes dans ce palier maximal. Pour CVE-2025-39682, le délai de trois jours s’applique à l’ensemble des actifs. Pour les deux autres, la règle distingue les actifs exposés publiquement (trois jours) des actifs internes (quatorze jours, soit une échéance autour du 2 octobre 2026). La directive lie juridiquement les agences fédérales civiles américaines et leurs sous-traitants qui opèrent des systèmes couverts par contrat. Elle ne s’applique ni aux entreprises privées américaines, ni à aucune organisation en dehors des États-Unis.
Le prix du retard, ce que révèle le rapport Verizon DBIR 2026
Le calendrier de BOD 26-04 se heurte à une réalité documentée par le Data Breach Investigations Report 2026 de Verizon, cité comme référence par la CISA elle-même. Seules 26% des failles du catalogue KEV ont été entièrement corrigées en 2025, contre 38% l’année précédente. Le délai médian pour une remédiation complète est passé de 32 à 43 jours sur la même période. Même les organisations les plus performantes ne parviennent à traiter que 30 à 40% de leurs failles KEV dans la première semaine suivant leur détection, un chiffre resté stable depuis trois ans malgré l’arrivée de nouveaux outils.
Le volume lui-même s’est alourdi. Le nombre de failles KEV à traiter en 2025 a augmenté de 50% par rapport à l’année précédente. Cette pression croissante, combinée à une base de correctifs déjà en retard, rend la fenêtre de 72 heures moins réaliste qu’elle n’y paraît, même si l’objectif affiché par la CISA n’est pas d’atteindre 100% de conformité mais de transformer les expositions les plus critiques en urgence opérationnelle, devant toute autre tâche planifiée.
| Indicateur (rapport Verizon DBIR) | 2024 | 2025 | Évolution |
|---|---|---|---|
| Failles KEV entièrement corrigées | 38% | 26% | -12 points |
| Délai médian de remédiation complète | 32 jours | 43 jours | +11 jours |
| Volume de failles KEV à traiter | Référence | +50% | Forte hausse |
| Remédiation en 1 semaine (meilleurs élèves) | 30 à 40% | 30 à 40% | Stable |
Pourquoi cette alerte dépasse les frontières américaines
BOD 26-04 ne contraint légalement que les agences fédérales américaines. Mais le catalogue KEV de la CISA fonctionne, dans les faits, comme une référence de priorisation largement suivie par les équipes de sécurité en Europe, y compris par des CERT nationaux qui s’appuient régulièrement sur ses entrées pour construire leurs propres bulletins. Les trois composants concernés, kTLS, ebtables et AF_ALG, tournent sur une bonne partie des infrastructures Linux qui hébergent des services web en France et ailleurs sur le continent, chez des hébergeurs comme chez des opérateurs cloud.
L’Union européenne construit sa propre version d’un mécanisme d’alerte rapide sur les failles activement exploitées. Le Cyber Resilience Act impose déjà aux fabricants de signaler à l’ENISA toute faille activement exploitée sous 24 heures, un délai encore plus court que celui fixé par la CISA pour ses propres agences. La logique reste la même des deux côtés de l’Atlantique : une exploitation confirmée doit déclencher une réaction mesurée en heures, pas en semaines.
La directive NIS2, transposée dans le droit français, impose par ailleurs aux entités essentielles et importantes des obligations de gestion des vulnérabilités et de réponse aux incidents qui recoupent largement l’esprit du catalogue KEV, sans jamais le citer directement. Une entité soumise à NIS2 qui ignorerait une faille inscrite au catalogue de la CISA, avec exploitation active confirmée par Red Hat, aurait du mal à justifier cette inaction devant un régulateur en cas d’incident.
kTLS, l’optimisation invisible qui fait tourner une partie du web
kTLS reste largement méconnu en dehors des équipes qui administrent des infrastructures à fort trafic, alors qu’il équipe une partie non négligeable des serveurs qui délivrent du contenu chiffré chaque jour. Nginx propose sa prise en charge via un moteur ktls associé à la directive ssl_protocols TLSv1.3. Certaines versions d’OpenSSL embarquent un fournisseur ktls dédié. Des CDN, des reverse proxies et des serveurs de bases de données activent la fonctionnalité pour réduire la charge CPU liée au déchiffrement TLS à grande échelle.
L’identification des systèmes exposés à CVE-2025-39682 demande un peu de travail, car kTLS s’active au niveau applicatif, pas au niveau noyau seul. Un noyau peut techniquement le supporter sans qu’aucune application ne l’active jamais. Quelques commandes simples aident à faire le tri :
# Vérifier si kTLS est actif sur les sockets ouverts
ss -npt | grep tls
# Identifier la version du noyau en cours d'exécution
uname -r
# Vérifier si le module af_alg est chargé
lsmod | grep af_algLes environnements multi-tenant méritent une attention particulière. Un hébergeur qui exécute des charges de travail de clients différents sur un même noyau, avec kTLS activé pour accélérer le chiffrement, expose potentiellement l’ensemble des locataires si un processus compromis parvient à atteindre le chemin de réception TLS du noyau.
Une semaine chargée pour le noyau Linux
Les trois CVE inscrites au catalogue KEV le 18 septembre ne sont pas les seules failles noyau révélées cette semaine-là. Le chercheur en sécurité Asim Manizada a publié, au même moment, quatre vulnérabilités distinctes d’élévation de privilèges locale : DirtyAH6 (CVE-2026-80844), TUNderflow (CVE-2026-81000), PPPoEject (CVE-2026-68121) et DiagSpill (CVE-2026-74469). Aucune des quatre n’a, à ce stade, rejoint le catalogue KEV, ce qui signifie que la CISA n’a pas confirmé d’exploitation active à leur sujet. Leur publication simultanée reflète tout de même un intérêt soutenu des chercheurs, et probablement des attaquants, pour les sous-systèmes réseau et cryptographique du noyau Linux.
Ce n’est pas non plus la première fois que le chemin de réception TLS attire l’attention. Le site avait déjà documenté une vague de six CVE touchant TLS 1.3 en six semaines plus tôt cette année, ainsi qu’une faille paralysant l’implémentation crypto/tls du langage Go et des CVE touchant GnuTLS et wolfSSL. La complexité de la désambiguïsation de type après déchiffrement en TLS 1.3, combinée à un accès mémoire noyau, en fait une zone que chercheurs et attaquants continuent de scruter de près.
Rétrospective, de BOD 19-02 à BOD 26-04
Le catalogue KEV lui-même remonte à novembre 2021, quand la CISA l’a créé sous l’autorité de BOD 22-01, en réponse à une série d’incidents majeurs qui avaient révélé l’écart entre la publication d’un correctif et son application réelle sur le terrain. BOD 22-01 imposait un délai fixe, généralement de deux semaines, calculé uniquement à partir de la présence au catalogue, sans tenir compte du contexte d’exposition de l’actif concerné.
BOD 26-04, en juin 2026, corrige ce défaut structurel en introduisant une évaluation à quatre facteurs. L’idée sous-jacente est simple : toutes les failles KEV ne se valent pas. Une vulnérabilité exploitée dans la nature sur un serveur exposé publiquement, avec un exploit automatisable et un impact potentiel de compromission totale du système, mérite un traitement différent d’une faille similaire sur un actif interne isolé. Le modèle à quatre variables permet cette granularité, au prix d’une complexité de mise en œuvre supérieure pour les équipes chargées de l’évaluer en continu.
L’obligation de triage forensique constitue le changement le plus structurant. Pour CVE-2025-39682, dont la preuve de concept circule publiquement depuis septembre 2025, les systèmes vulnérables ont potentiellement été exposés à des tentatives d’exploitation pendant près d’un an avant l’inscription au catalogue. Le triage impose désormais de vérifier les journaux de crash noyau, les sorties KASAN et les journaux d’audit à la recherche de signes d’élévation de privilèges antérieure au correctif, plutôt que de se contenter d’appliquer le patch.
Impact sur le marché, distributions et fournisseurs cloud
Red Hat porte l’essentiel de la charge de communication publique sur ce dossier, avec des avis détaillés pour les trois CVE et des correctifs disponibles pour RHEL 9 et RHEL 10. Amazon référence également CVE-2025-39682 sur sa page de sécurité Amazon Linux, ce qui confirme une exposition potentielle des instances EC2 tournant sur des noyaux non corrigés. Les solutions de patch à chaud, kpatch chez Red Hat et Canonical Livepatch chez Ubuntu, permettent d’appliquer certains correctifs sans redémarrage, un avantage réel pour les infrastructures critiques qui ne peuvent pas absorber une coupure de service sur une fenêtre de 72 heures.
Pour les hébergeurs et les CDN qui activent kTLS afin de réduire leur facture CPU sur le déchiffrement TLS, la mise à jour noyau représente un chantier de maintenance non négligeable. Contrairement à un correctif applicatif classique, les trois fixes exigent une mise à jour noyau suivie d’un redémarrage, sauf disponibilité confirmée d’un patch à chaud compatible. Les environnements conteneurisés méritent une vigilance particulière pour CVE-2026-53266, où les configurations réseau pontées avec des règles ebtables SNAT restent courantes dans certains déploiements de virtualisation.
Ce que les équipes techniques doivent vérifier avant la prochaine alerte
Quelques réflexes s’imposent, que l’organisation soit ou non soumise à BOD 26-04. Premièrement, identifier précisément les versions de noyau en circulation dans le parc, en gardant en tête que CVE-2025-39682 touche les noyaux 6.0 à 6.16.3, plus les versions candidates 6.17-rc1 et 6.17-rc2, tandis que CVE-2025-39964 couvre une plage bien plus large, de 2.6.38 jusqu’à 6.16.9 et 6.17-rc6. Deuxièmement, vérifier l’usage réel de kTLS via les sockets actifs plutôt que de se fier à la seule version du noyau, puisque la fonctionnalité s’active côté application.
Troisièmement, auditer les règles ebtables en place, en particulier dans les environnements conteneurisés ou virtualisés qui s’appuient sur un pontage réseau avec renattage d’adresses. Un chantier de durcissement des clusters Kubernetes contre les CVE containerd traite d’ailleurs des mêmes réflexes d’audit réseau. Quatrièmement, envisager le blocage temporaire du module af_alg comme mesure conservatoire là où le patch complet ne peut pas être déployé immédiatement. Cinquièmement, et c’est le point le plus souvent oublié, prévoir le triage forensique, pas seulement le patch : consulter les journaux de crash noyau et les traces d’audit sur toute la période d’exposition, potentiellement longue de plusieurs mois.
Cinq prévisions pour la suite
- D’autres CVE noyau devraient rejoindre le palier de remédiation le plus agressif de BOD 26-04 dans les prochains mois, à mesure que le modèle à quatre variables se stabilise et que la CISA affine ses critères d’automatisation de l’exploit.
- Les éditeurs de distributions vont probablement accélérer la publication de correctifs à chaud pour couvrir plus rapidement les CVE classées KEV, sous la pression d’un délai de 72 heures devenu la nouvelle norme de facto.
- Les CERT européens, y compris en France, devraient continuer d’aligner leurs propres bulletins sur le catalogue KEV, sans que la directive américaine ne s’applique juridiquement sur le continent.
- Le chemin de réception kTLS, déjà sondé par plusieurs équipes de recherche en 2026, restera une cible privilégiée des chercheurs en sécurité noyau, avec probablement de nouvelles découvertes dans le mode zero-copy au cours des prochains mois.
- L’écart de remédiation documenté par le rapport Verizon DBIR, 26% de failles KEV entièrement corrigées en 2025, risque de se creuser encore en 2026 si le volume continue de croître au même rythme que l’an dernier, ce qui pourrait pousser la CISA à revoir une nouvelle fois sa doctrine de priorisation.
Pour l’instant, la fenêtre reste étroite. Le délai fédéral de 72 heures est déjà dépassé, ce qui déplace la priorité vers le triage forensique, pas seulement vers l’application du patch. Les organisations qui n’ont pas encore vérifié leur exposition à kTLS, à ebtables SNAT ou à AF_ALG gagneraient à traiter ce trio comme une urgence, indépendamment du texte réglementaire qui les gouverne.
Questions fréquentes
Qu’est-ce que le catalogue KEV de la CISA ?
Le Known Exploited Vulnerabilities Catalog recense les failles pour lesquelles la CISA dispose de preuves d’exploitation active confirmée, par opposition à une simple vulnérabilité publiée sans preuve d’attaque réelle. Créé en novembre 2021 sous l’autorité de BOD 22-01, il sert aujourd’hui de référence de priorisation bien au-delà des agences fédérales américaines qu’il vise juridiquement.
Le délai de 72 heures s’applique-t-il aux entreprises françaises ?
Non. BOD 26-04 ne lie juridiquement que les agences fédérales civiles américaines et leurs sous-traitants opérant des systèmes couverts par contrat. Les entreprises françaises et européennes n’y sont pas soumises, mais le niveau de risque documenté, une exploitation active confirmée sur trois composants noyau, reste identique quelle que soit la juridiction.
Comment savoir si mes serveurs utilisent kTLS ?
kTLS s’active au niveau applicatif via un appel setsockopt() avec l’option TCP_ULP réglée sur “tls”, pas au niveau du noyau seul. La commande ss -npt | grep tls permet de repérer les sockets concernés. Une vérification de la configuration du serveur web, à la recherche de références au moteur ktls chez Nginx par exemple, complète l’audit.
Existe-t-il un correctif sans redémarrage du serveur ?
Pas pour les trois CVE dans leur ensemble à ce stade. Les solutions de patch à chaud comme kpatch chez Red Hat ou Canonical Livepatch chez Ubuntu peuvent, selon les cas, appliquer certains correctifs noyau sans coupure de service, mais leur couverture de ces trois références précises dépend du calendrier de publication propre à chaque éditeur.
Pourquoi les scores CVSS diffèrent-ils autant d’un organisme à l’autre ?
Red Hat, le NVD et cve.org évaluent parfois différemment l’impact réel d’une faille selon la version et la configuration retenues par chaque produit. Pour CVE-2025-39682 par exemple, Red Hat retient un score de 7,0 en tenant compte du contexte de ses propres distributions, contre 9,8 chez le NVD et cve.org. La CISA recommande de se fier à l’inscription au catalogue KEV plutôt qu’au seul score CVSS pour juger de l’urgence.
Quelle est la faille la plus dangereuse des trois ?
Aucun consensus unique ne se dégage, mais CVE-2025-39682 concentre le plus d’attention : une preuve de concept publique circule et le composant touché équipe une partie significative des serveurs à fort trafic. CVE-2025-39964, malgré un score parfois jugé modéré, couvre une plage de versions bien plus large, remontant jusqu’au noyau 2.6.38.
Que signifie l’obligation de “triage forensique” introduite par BOD 26-04 ?
Elle impose de déterminer si un système a été compromis avant même l’application du correctif, en examinant les journaux de crash noyau, les sorties d’outils comme KASAN et les journaux d’audit. C’est un changement par rapport à l’ancien modèle de BOD 22-01, qui s’arrêtait à l’application du patch sans exiger cette vérification rétroactive.
Le Cyber Resilience Act européen impose-t-il un délai similaire ?
Le CRA impose aux fabricants de produits numériques de signaler à l’ENISA toute faille activement exploitée sous 24 heures, un délai encore plus court que celui fixé par la CISA pour ses propres agences fédérales, même si le périmètre des obligations reste différent entre les deux textes.
Où trouver le détail technique complet de ces failles ?
Les pages officielles de cve.org et de Cybersecurity News détaillent la chronologie des trois CVE et leur statut de correctif par distribution. Notre dossier cryptographie suit également l’évolution des failles touchant les mécanismes de chiffrement du noyau et des bibliothèques TLS.
