Trois anciens bogues du noyau Linux ajoutés à la liste KEV de la CISA

En bref

Aller directement à la version longue ↓

De quoi s'agit-il ? Le 18 septembre 2026, la CISA a ajouté trois vulnérabilités du noyau Linux à son catalogue des vulnérabilités connues pour avoir été exploitées. La vulnérabilité CVE-2025-39682 se situe dans le chemin de réception TLS du noyau, la vulnérabilité CVE-2026-53266 se trouve dans la cible SNAT ebtables utilisée sur les ponts réseau, et la vulnérabilité CVE-2025-39964 est une condition de concurrence sur les sockets cryptographiques AF_ALG. Trois sous-systèmes sans lien entre eux, trois tests d'exposition différents. Aller à cette section →

Impact : il varie bien davantage que ne le laissent entendre les gros titres. Le bogue kTLS permet aux enregistrements ultérieurs d’être traités selon des hypothèses erronées concernant le « zero-copy » et la mise en file d’attente. Le bogue ebtables peut entraîner l’écriture par le noyau dans une page adossée à un fichier qu’il n’était pas censé modifier par ce chemin, ce que Red Hat décrit comme pouvant conduire à une corruption de mémoire, un déni de service ou une élévation de privilèges. La condition de concurrence AF_ALG provoque à elle seule un plantage local ou une sortie cryptographique corrompue, mais un code d’exploitation public l’enchaîne désormais pour obtenir un shell root sur un noyau ciblé. Aller à cette section →

Gravité : la situation est plus nuancée que ne le laissent entendre les gros titres. Red Hat leur attribue respectivement les notes de 7,0, 7,5 et 7,3, et les classe dans les catégories « Modérée », « Importante » et « Modérée », car son échelle de gravité ne se limite pas à la simple valeur numérique. Le NVD et le Linux CNA utilisent des vecteurs différents pour certaines de ces vulnérabilités, ce qui explique les notes plus élevées de 9,8, 8,8 et 7,8. Aller à cette section →

Qui est concerné : RHEL et ses dérivés, notamment AlmaLinux, Rocky Linux, Oracle Linux et CloudLinux, avec un périmètre qui varie selon le CVE. Pour le CVE-2025-39682, Red Hat indique que seules les versions EL9 et EL10 sont concernées. Les deux autres CVE ont une portée plus large, et le CVE-2026-53266 mentionne désormais même RHEL 6, qui bénéficie d’un support étendu. Chaque vulnérabilité est également soumise à une condition préalable qui réduit l'exposition réelle. Aller à cette section →

Statut : Il ne s'agit pas de failles « zero-day ». Tous les correctifs en amont sont antérieurs à la publication de cette liste, notamment ceux concernant kTLS et AF_ALG, qui remontent à plus d'un an. Les registres de Red Hat signalent désormais ces trois failles comme des exploits connus, mais ni la CISA ni Red Hat n'ont publié de chaîne d'attaque, de cibles ou de données télémétriques au-delà du statut lié à KEV, et l'utilisation par des ransomwares est répertoriée comme inconnue. Du code d'exploit public existe désormais pour deux de ces trois failles. Aller à cette section →

Procédez ainsi dès maintenant : installez un noyau fournisseur fixe et redémarrez avec celui-ci, ou laissez KernelCare appliquer les correctifs « live » sans redémarrage lorsqu’ils sont disponibles pour le noyau en cours d’exécution. Et ignorez la liste noire du module af_alg. Sur les noyaux Enterprise Linux vérifiés ici, AF_ALG est intégré, la liste noire n’a donc aucun effet. Aller à cette section →

Avant de vous fier à une solution de contournement af_alg, vérifiez comment AF_ALG est intégré au noyau en cours d'exécution :

grep -E 'CONFIG_CRYPTO_USER_API' /boot/config-(uname-r)2>/dev/null||grep-E'CONFIGCRYPTOUSERAPI'/lib/modules/(uname -r)/config

Si CONFIG_CRYPTO_USER_API=y apparaît dans la sortie, AF_ALG est intégré à la compilation et aucune liste noire de modules ne permet de le désactiver.

Le fait que trois CVE du noyau aient été enregistrées dans KEV le même jour peut donner l'impression qu'il s'agit d'un seul et même incident. Il s'agit en réalité de trois incidents distincts : ils ne partagent ni la même catégorie de faille, ni le même sous-système, et il n'existe aucun test unique permettant de déterminer si un hôte est vulnérable.

Ce qu’ils ont en revanche partagé, c’est le moment choisi et le battage médiatique qui l’a entouré. La publication s’accompagnait d’un délai de trois jours pour la mise en conformité des agences civiles fédérales, conformément à la directive BOD 26-04, et les articles qui ont suivi mentionnaient un score de gravité de 9,8 et affirmaient que Red Hat avait confirmé de manière indépendante une exploitation active des trois vulnérabilités. Les registres de Red Hat signalent effectivement ces CVE comme des failles connues, mais ce statut est lié à l’inscription sur la liste KEV plutôt qu’aux données télémétriques publiées par Red Hat ; quant à la note de 9,8, elle doit être replacée dans son contexte, car elle provient d’une méthode d’évaluation différente de celle utilisée par Red Hat pour RHEL.

Aucun de ces bogues n'est nouveau non plus. Le correctif kTLS a été intégré en amont le 19 août 2025, celui d'AF_ALG le 16 septembre 2025 et celui d'ebtables le 23 mai 2026. Il s'agit donc d'un problème de délai de correction de n jours, et la question pertinente pour chaque hôte est de savoir si le correctif a effectivement été intégré au noyau qui est actuellement en cours d'exécution.

Le 18 septembre, la CISA a ajouté ces trois CVE au catalogue KEV et a fixé au 21 septembre la date limite de correction prévue par la directive BOD 26-04 pour les agences civiles fédérales. Trois jours, c'est court selon les normes du KEV.

Cette inclusion signifie que la CISA dispose de preuves d’exploitation qu’elle juge fiables. Cela ne signifie pas pour autant que ces preuves soient publiques, ce qui n’est d’ailleurs pas le cas ici. Les entrées du catalogue ne contiennent aucun détail technique, l’alerte qui les accompagne ne mentionne ni les chaînes d’attaque ni les cibles, et les trois entrées indiquent « Inconnu » concernant l’utilisation dans le cadre de campagnes de ransomware connues.

Les bases de données de Red Hat comportent désormais un indicateur « exploit connu » pour ces trois vulnérabilités, mais Red Hat n'a pas publié ses propres détails concernant leur exploitation, les chaînes d'attaque, les cibles ou les données télémétriques ; cet indicateur reprend la liste fournie par KEV plutôt que de refléter des observations indépendantes de Red Hat. Il convient de le considérer comme le même signal que celui fourni par KEV, et non comme une source secondaire.

Considérez donc cette liste comme un indicateur fiable montrant que la CISA dispose de preuves attestant que ces vulnérabilités sont exploitées, puis évaluez chacune d’entre elles en fonction de ses conditions préalables réelles. La désignation « KEV » renforce la priorité, mais l’urgence pratique dépend toujours de la possibilité d’accéder à chaque voie vulnérable sur l’hôte.

Les chiffres de 9,8, 8,8 et 7,8 qui circulent sont réels, et les notes spécifiques aux produits de Red Hat sont encore différentes : 7,0 pour CVE-2025-39682, 7,5 pour CVE-2026-53266 et 7,3 pour CVE-2025-39964. Ces différences s'expliquent par des vecteurs d'attaque différents et des hypothèses divergentes concernant l'exploitabilité et l'impact.

La vulnérabilité CVE-2025-39682 en est un bon exemple. Le NVD lui attribue une note de 9,8, tandis que Red Hat lui attribue une note de 7,0 pour RHEL. Les deux organismes la considèrent comme accessible depuis le réseau, mais Red Hat lui attribue un niveau de complexité d’attaque « élevé » et un impact moindre sur la confidentialité et l’intégrité, ce qui fait que cette même faille se retrouve classée dans une catégorie très différente.

Cette distinction est importante pour l'analyse, mais elle ne doit pas servir de prétexte pour retarder la mise en place des mesures correctives. Ces trois éléments figurent dans le catalogue KEV de la CISA, et la question pertinente n'est pas de savoir quelle note l'emporte. Vérifiez si la voie d'exploitation de la vulnérabilité est accessible sur vos systèmes, établissez vos priorités en fonction de cela, appliquez le noyau corrigé ou le correctif en temps réel, puis vérifiez que le noyau en cours d'exécution est bien protégé.

La vulnérabilité CVE-2025-39682 se situe au niveau de la réception du protocole TLS du noyau, c'est-à-dire la couche de paquets intégrée au noyau qui permet aux applications de déléguer au noyau une partie du traitement des paquets TLS après la phase d'établissement de la connexion.

Chacun recvmsg() Cette fonction est censée traiter soit une série d'enregistrements de données contigus, soit un seul enregistrement non lié aux données, mais en aucun cas un mélange des deux. Un enregistrement de longueur nulle déjà placé en file d'attente sur rx_list Il passe inaperçu lors de la vérification du type d'enregistrement, ce qui fait que les enregistrements suivants sont traités selon des hypothèses erronées concernant la copie zéro et la mise en file d'attente. Cette incohérence remet en cause les hypothèses du chemin de réception concernant les enregistrements et les tampons qu'il contient, ce qui explique pourquoi Red Hat considère ce problème comme plus grave qu'un simple bug de disponibilité.

Ce qui compte, c'est l'accessibilité. Avoir CONFIG_TLS au niveau du noyau ne suffit pas. Le protocole de couche supérieure TLS doit être associé à une socket TCP, ce qui n’est possible que lorsque l’utilisateur a expressément choisi cette option, par exemple dans le cas d’un déploiement nginx configuré pour utiliser kTLS, d’une application développée avec une chaîne OpenSSL kTLS compatible, ou d’un NFS sur TLS via tlshd. Lorsque le kTLS est activé intentionnellement et que l'application permet de le désactiver, la désactivation de l'offload ramène le traitement des enregistrements dans l'espace utilisateur, ce qui entraîne une certaine charge pour le processeur. Considérez cela comme une mesure d'atténuation provisoire, et non comme un substitut à l'application d'un correctif.

La correction se trouve dans le commit en amont 62708b9452f8, datée du 19 août 2025. Red Hat a publié des noyaux RHEL 9 et RHEL 10 corrigés le 29 septembre 2025, suivis fin octobre par les branches 9.2 SAP et 9.4 EUS. Pour ce CVE, Red Hat indique que RHEL 6, 7 et 8 ne sont pas affectés. Le code vulnérable a été introduit en amont dans Linux 6.0 et est présent dans les branches du noyau RHEL 9 et 10, mais pas dans RHEL 8 (basé sur la version 4.18) ni dans les versions antérieures. Un code d’exploitation public a depuis fait son apparition ; il exploite cette faille pour provoquer une corruption de la mémoire du noyau et obtenir un shell root sur une cible spécifique de kernelCTF. Bien qu’il ne s’agisse pas d’un exploit portable pour les noyaux RHEL en production, cela signifie néanmoins que le bug du chemin de réception a été transformé en arme quelque part.

Le bogue SNAT d'Ebtables qui écrit dans la mauvaise page

La vulnérabilité CVE-2026-53266 présente le score CVSS Red Hat le plus élevé des trois, soit 7,5, avec un niveau de gravité « Important » selon Red Hat, et c'est celle qui présente le mode de défaillance le plus intéressant.

La cible SNAT d'ebtables peut, si nécessaire, réécrire l'adresse matérielle de l'expéditeur dans les paquets ARP lorsqu'ils traversent un pont. Elle procède ainsi via skb_store_bits(), qui écrit dans les fragments non linéaires du paquet. L'un de ces fragments peut être adossé à une page de fichier importée via splice, de sorte que l'écriture peut aboutir dans une page associée à un fichier qu'elle n'était pas censée modifier par ce biais. Red Hat associe ce problème au CWE-825 et décrit ce phénomène comme pouvant conduire à une corruption de mémoire, à un déni de service ou à une élévation de privilèges.

La condition préalable est stricte. Il faut qu’il existe une règle SNAT ebtables configurée par l’administrateur avec réécriture ARP sur un pont, et un attaquant ne peut pas en activer une. De nombreux hôtes connectés via un pont n’utilisent jamais le NAT ebtables. Pour une première vérification rapide, inspectez la table NAT à la recherche d’une règle SNAT avec réécriture ARP :

sudo ebtables -t nat -L | grep -i 'snat-arp'

Considérez cela comme une vérification initiale de la configuration plutôt que comme une preuve définitive dans un sens ou dans l'autre. L'absence de résultat correspondant indique clairement que la règle n'est pas configurée sur cet hôte. Une correspondance devrait faire remonter l'hôte en tête de la file d'attente de correction, sous réserve de votre propre processus de modification. Si la réécriture n'est pas réellement nécessaire, la désactivation de cette règle spécifique peut réduire la vulnérabilité jusqu'à ce que le noyau corrigé soit en place, mais veillez à valider la modification par rapport à l'architecture du réseau avant de l'appliquer.

La correction en amont correspond au commit 67ba971ae025, daté du 23 mai 2026. Red Hat avait corrigé les versions RHEL 8 et 9 en juillet, bien avant la publication de la liste, puis avait poursuivi avec RHEL 10 et RHEL 7 ELS le 24 septembre, avant de corriger RHEL 6 ELS le 30 septembre. La version RHEL 9 kernel-rt est toujours signalée comme concernée.

Deux programmes d'écriture sur un seul socket AF_ALG

CVE-2025-39964 est un bogue de concurrence dans AF_ALG, l'interface de socket qui expose l'API de cryptographie du noyau à l'espace utilisateur. Deux écritures simultanées sur la même socket AF_ALG peuvent s'entremêler et rendre le contexte propre à chaque socket incohérent.

Red Hat décrit cette faille directe comme permettant à un utilisateur local de provoquer un plantage du système ou de corrompre des résultats cryptographiques. Les notes divergent ensuite. La note principale du NVD est de 5,5, portant uniquement sur l’impact sur la disponibilité. Le Linux CNA l’évalue à 7,8, tandis que Red Hat lui attribue une note de 7,3, avec un vecteur qui inclut également l’impact sur la confidentialité et l’intégrité. Ce qui fait pencher la balance, c’est l’existence d’un exploit public. Un dépôt enchaîne la course à la corruption de la mémoire du noyau, divulgue une adresse du noyau, écrase core_pattern, et parvient à obtenir un shell root. Les notes de l’auteur lui-même ainsi qu’une analyse indépendante soulignent à la fois la présence de décalages codés en dur et d’un contournement du KASLR qui pourrait ne pas fonctionner sur tous les noyaux ; il s’agit donc d’une chaîne d’escalade de privilèges validée sur une version ciblée plutôt que d’un exploit portable contre les versions prises en charge de RHEL. Quoi qu’il en soit, l’hypothèse selon laquelle l’exploitation ne provoquerait qu’un plantage n’est plus valable, ce qui revêt une importance particulière sur les hôtes partagés ou multi-locataires.

La correction en amont correspond au commit 1b34cbbf4f01, datée du 16 septembre 2025. Il s'agit également de la vulnérabilité CVE pour laquelle Red Hat a fourni des correctifs le plus rapidement après sa publication. Le 21 septembre, Red Hat n'avait publié aucune errata à ce sujet pour aucun de ses produits. La première errata est apparue le 22 septembre, et dès le 24 septembre, des correctifs avaient été fournis pour RHEL 8, 9, 10 et RHEL 7 ELS, ainsi que pour les versions bénéficiant d'un support étendu.

La solution de contournement AF_ALG qui ne sert à rien

Celui-là va en faire mordre plus d'un.

Les recommandations précédentes de Red Hat concernant la vulnérabilité CVE-2025-39964 conseillaient d'empêcher la af_alg le chargement du module. La page actuelle ne contient plus cette ligne, et c'est tant mieux, car elle n'a jamais fonctionné sur les noyaux Enterprise Linux testés ici. AF_ALG y est intégré au noyau plutôt que fourni sous forme de module chargeable. Les noyaux fournis avec AlmaLinux 8, 9 et 10 ainsi qu'avec CloudLinux 8 définissent CONFIG_CRYPTO_USER_API=y, avec l'implémentation AF_ALG et ses interfaces intégrées. Le modules.builtin listes de fichiers kernel/crypto/af_alg.ko, et le paquet ne contient aucun fichier séparé af_alg.ko.

A modprobe.d La liste noire peut donc être acceptée sans générer d'erreur, mais elle ne peut pas désactiver un composant intégré. Il en va de même pour modprobe.blacklist=af_alg dans la ligne de commande du noyau. Aucun paramètre sysctl ni paramètre de démarrage pris en charge permettant de désactiver AF_ALG n’a été trouvé dans les configurations testées.

Et le calcul que la plupart des gens font partent du principe inverse :

lsmod | grep af_alg

Une sortie vide ne prouve pas que AF_ALG soit inactif. Sur les noyaux vérifiés ici, cela correspond au fait qu’AF_ALG soit intégré au noyau plutôt que chargé en tant que module, ce que vous pouvez confirmer à l’aide de la commande CONFIG_CRYPTO_USER_API la commande « grep » mentionnée au début de cet article et avec modules.builtin. Un hôte ne doit pas être considéré comme protégé simplement parce que cette commande ne renvoie aucun résultat. Si la configuration indique =y, les seules options possibles sont un noyau patché ou un correctif sans redémarrage. Dans le cadre d'une défense en profondeur, une politique seccomp soigneusement testée peut bloquer socket() nécessite l'utilisation de la famille d'adresses AF_ALG pour certaines charges de travail, mais cela dépend de la charge de travail en question et n'apporte aucune protection contre les utilisateurs locaux ordinaires sur l'hôte.

Voici où en étaient les trois principales familles d’Enterprise Linux d’après les sources examinées jusqu’au 2 octobre 2026. Chaque cellule indique en premier lieu le statut du noyau du fournisseur et, pour AlmaLinux et CloudLinux, précise la couverture « sans redémarrage » de KernelCare lorsque celle-ci diffère, car il s’agit de deux types de correctifs distincts. Veuillez vous référer aux libellés plutôt qu’aux seules dates :

Rocky Linux et Oracle Linux ne figurent pas dans le tableau ci-dessus, mais ils s’appuient sur le même code en amont que RHEL ; il convient donc de consulter les avis de sécurité propres à chacun et de vérifier le noyau exact en cours d’exécution plutôt que de supposer que les dates correspondent. Les branches « Extended Update Support » (EUS) de Red Hat pour RHEL 8 (8.4, 8.6, 8.8) et RHEL 9 (9.2, 9.4, 9.6) ont également bénéficié de correctifs entre le 23 et le 24 septembre, tandis que les versions majeures plus anciennes, RHEL 6 et 7, sont prises en charge par le support de cycle de vie prolongé (ELS), auquel font référence les mentions ELS dans le tableau.

Deux petites remarques. Sur CloudLinux 8, les noyaux provenant de 4.18.0-553.142.1 Les versions ultérieures intègrent déjà le correctif CVE-2026-53266, alors vérifiez uname -r avant de supposer l'existence d'une faille. Fin septembre, Red Hat a modifié le statut de RHEL 6, passant de « Non concerné » à « Concerné » pour la vulnérabilité CVE-2026-53266, et a publié un correctif ELS pour RHEL 6 le 30 septembre, ce qui concerne tous ceux qui utilisent encore RHEL 6 ou CloudLinux 6 dans le cadre du support à cycle de vie prolongé (ELS).

Debian, Ubuntu et Amazon Linux assurent le suivi de ces CVE selon leur propre calendrier. Consultez l'avis de sécurité correspondant à votre noyau plutôt que de vous référer à celui de RHEL.

Les correctifs sans redémarrage de KernelCare couvrent également les branches RHEL, comme l'indique la chronologie dans l'encadré situé en haut de cet article ; la ligne « RHEL » ci-dessus fait donc référence aux noyaux développés par Red Hat lui-même, et non à l'absence d'une option de correctif sans redémarrage.

Procurez-vous KernelCare dès aujourd’hui →

Un paquet de noyau corrigé présent sur le disque ne modifie pas le noyau en mémoire. Pour une mise à jour classique, installez les paquets de noyau corrigés correspondant exactement à votre version, redémarrez, puis vérifiez ce qui est réellement en cours d'exécution :

uname -r

Comparez cela avec l'avis de Red Hat ou celui concernant la reconstruction du système, et non avec la version la plus récente présente sur le disque. Un hôte sur lequel la mise à jour a été installée il y a trois semaines et qui n'a jamais été redémarré utilise toujours l'ancien noyau.

Lorsqu'un correctif pris en charge est disponible, KernelCare applique les correctifs correspondants au noyau actif sans redémarrage. Ces correctifs sont diffusés sous forme de correctifs « live » sans redémarrage sur les flux mentionnés précédemment, et leur disponibilité reste spécifique à chaque noyau. Les configurations pour lesquelles les mises à jour automatiques sont activées récupèrent périodiquement les nouveaux correctifs, et kcarectl --update en demande une à la demande. Vérifiez laquelle des trois est prise en charge par le noyau en cours d'exécution :

kcarectl --patch-info | grep -E 'CVE-2025-39682|CVE-2026-53266|CVE-2025-39964'

Si aucun CVE n'apparaît pour le noyau en cours d'exécution, ne déduisez pas la couverture à partir d'une autre distribution, d'une autre branche mineure ou d'une mise à jour de paquet qui n'a jamais été démarrée, et maintenez en place toute mesure d'atténuation provisoire validée jusqu'à ce que ce soit le cas. CloudLinux 8 constitue un cas particulier : un noyau récent peut déjà contenir le correctif du CVE-2026-53266 de manière native, même si une requête « live-patch » n'affiche aucun correctif distinct.

Non. Tous les correctifs avaient déjà été rendus publics en amont avant la publication de la liste, et Red Hat avait mis à disposition des noyaux corrigés pour la vulnérabilité CVE-2025-39682 près d'un an auparavant. La seule nouveauté rendue publique est la désignation « KEV » attribuée par la CISA, qui indique que ces vulnérabilités font l'objet d'exploitations connues, sans toutefois fournir de détails publics sur ces exploitations. C'est un scénario « n-day » bien connu. Les anciens correctifs du noyau qui n'ont jamais été appliqués constituent précisément la cible privilégiée des attaquants.

Il convient toutefois d’être précis concernant le code d’exploitation. Il existe désormais des dépôts publics contenant des PoC fonctionnels d’élévation de privilèges pour les vulnérabilités CVE-2025-39682 et CVE-2025-39964, tous deux conçus pour des cibles spécifiques de type « kernelCTF » avec des décalages codés en dur. Il s’agit là d’une véritable « weaponisation », et non d’un exploit portable contre un parc de machines de production corrigées mais non redémarrées ; par conséquent, affirmer qu’« il n’existe aucun PoC public » est tout simplement faux à ce stade, même si l’affirmation selon laquelle « n’importe qui peut obtenir les droits root sur n’importe quel hôte » est tout aussi erronée.

Pourquoi le « KEV Kernel Trio » est-il si important ?

Aucune de ces trois failles ne dispose d’une voie d’attaque large et sans condition préalable. L’une nécessite kTLS, une autre une règle ebtables spécifique configurée par l’administrateur, et la troisième un accès local, bien que des travaux publics sur les exploits montrent désormais une chaîne d’escalade de privilèges contre un noyau ciblé. C’est là le côté rassurant.

La leçon à tirer se trouve dans tout ce qui les entoure. Ces trois problèmes pouvaient être corrigés avant même que la CISA ne se prononce, et la correction en amont, les rétroportages des éditeurs, le déploiement sur le parc informatique et l’exploitation ne se déroulent pas selon le même calendrier. Dans le même temps, les notes de vulnérabilité en circulation ont induit les utilisateurs en erreur quant au degré d’urgence, et une solution de contournement proposée plus tôt par un fournisseur pour un CVE n’a, en réalité, eu aucun effet sur les noyaux qu’elle était censée protéger. Le délai de trois jours s’est également écoulé avant que Red Hat n’ait livré quoi que ce soit pour le CVE-2025-39964 ; le noyau du fournisseur n’était donc tout simplement pas disponible lorsque la date limite fédérale de correction est arrivée pour ce cas précis.

Pour les parcs informatiques mis à jour de manière classique, installez les noyaux corrigés et redémarrez selon un calendrier raisonnable, en commençant par les hôtes utilisant la réécriture ARP via ebtables et les hôtes kTLS. Pour les parcs où la coordination des redémarrages constitue un goulot d'étranglement, KernelCare ferme les chemins concernés dans le noyau en cours d'exécution tout en permettant la poursuite de la maintenance normale.

Procurez-vous KernelCare dès aujourd’hui →

Chronologie

Références

Les sources principales de cet article sont le catalogue des vulnérabilités connues pour lesquelles des exploits existent (version 2026.10.01) de la CISA, l’alerte de la CISA du 18 septembre 2026, la directive opérationnelle contraignante 26-04, ainsi que les pages CVE de Red Hat consacrées aux vulnérabilités CVE-2025-39682, CVE-2026-53266 et CVE-2025-39964, les entrées du NVD pour les CVE-2025-39682, CVE-2026-53266 et CVE-2025-39964, ainsi que les correctifs en amont 62708b9452f8, 67ba971ae025 et 1b34cbbf4f01.