Fragnesia et Cie : vague de vulnérabilités dans le noyau Linux

Il y a quelques semaines, j'écrivais un article sur Copy-Fail (CVE-2026-31431) où j'expliquais comment l'approche de défense en profondeur de Red Hat OpenShift avait empêché l'évasion de conteneur malgré un noyau vulnérable. J'avais passé du temps à essayer de m'extraire d'un conteneur OpenShift, j'avais obtenu les privilèges root dans le pod presque immédiatement, mais je n'avais toujours pas pu accéder à l'hôte. La vulnérabilité du noyau était réelle. Le chemin d'exploitation était réel. Les défenses ont tenu bon. 

Pendant que je terminais cet article, une autre variante associée, DirtyDecrypt (CVE-2026-31635), a commencé à circuler publiquement en parallèle des discussions sur l'exploitation et des démonstrations de faisabilité. À ce stade, nous observions quatre vulnérabilités majeures d'escalade de privilèges Linux en 14 jours environ, exploitant toutes des variations du même schéma global.

C'est l'aspect qui m'importe le plus.

À un moment donné, on cesse de les considérer comme des CVE isolées pour commencer à reconnaître un problème systémique. Différents sous-systèmes. Différents chemins d'exploitation. Même concept sous-jacent : manipuler le comportement de copie sur écriture au sein du cache de page du noyau, corrompre des fichiers censés être immuables et élever les privilèges.

Si vous gérez une infrastructure de production actuellement, cette prise de conscience change rapidement la donne. Traiter chaque CVE individuelle une à une commence à ressembler moins à une stratégie de sécurité qu'à une tentative d'attraper des flocons de neige avec la langue lors d'une avalanche. Le résultat final n'est pas beau à voir. 

L'important est de savoir si votre architecture reste résiliente lorsque la prochaine variante apparaîtra inévitablement.

Parce qu'à ce stade, ce sera probablement le cas.

Différentes CVE, même schéma

Au cours des deux dernières semaines, des chercheurs ont révélé plusieurs vulnérabilités liées : Copy-Fail ciblant la manipulation générale du cache de page, Dirty Frag s'attaquant aux chemins ESP/XFRM et RxRPC, Fragnesia ciblant l'ESP-in-TCP, et maintenant DirtyDecrypt faisant surface publiquement au sujet de rxgk. Les détails d'implémentation varient, mais la philosophie d'exploitation globale reste remarquablement cohérente. Les chercheurs trouvent une faiblesse conceptuelle dans une zone du code réseau du noyau, puis commencent à explorer les sous-systèmes adjacents à la recherche d'hypothèses similaires et de l'absence de mesures de protection. Ils en trouvent de plus en plus.

Ce schéma récurrent me préoccupe plus que n'importe quel numéro de CVE.

J'ai lancé un cluster ROSA et j'ai décidé de tester Fragnesia directement sur OpenShift. Le cluster exécutait OpenShift 4.21.15 sur Red Hat Enterprise Linux (RHEL) CoreOS 9.6 avec un noyau 5.14.0-570.113.1.el9_6.x86_64 vulnérable. Le sous-système vulnérable était présent. En théorie, l'environnement aurait dû être exploitable.

Je ne cherchais pas simplement à savoir si le noyau était vulnérable. Nous le savions déjà. Je voulais voir où la chaîne d'exploitation se romprait réellement selon différentes configurations de sécurité.

Tout d'abord, j'ai déployé un pod entièrement standard avec les protections par défaut d'OpenShift. Rien d'exceptionnel. Pas de privilèges élevés. Aucune SCC assouplie. Simplement un conteneur Fedora standard exécutant sleep infinity.

La chaîne d'exploitation a échoué presque immédiatement.

Le système a bloqué la création d'espaces de noms d'utilisateur avant que l'attaque ne puisse progresser de manière significative. Le sous-système vulnérable existait toujours, mais le conteneur n'a jamais obtenu les capacités nécessaires pour atteindre le chemin de code dangereux initialement. Les contraintes de contexte de sécurité (SCC) par défaut d'OpenShift, associées à l'application de SELinux, ont fermé la porte avant même que l'exploit ne commence réellement.

Cela n'était pas surprenant.

Ce qui m'intéressait davantage, c'était le scénario suivant, le type de configuration que de nombreuses organisations utilisent réellement.

J'ai créé une charge de travail à l'aide de la SCC anyuid et j'ai explicitement exécuté le conteneur avec l'identifiant d'utilisateur (UID) 0. C'est extrêmement courant dans les environnements « brownfield », des environnements existants où les applications héritées n'ont jamais été conçues selon le principe du moindre privilège et où les organisations font souvent des compromis parce que « l'application en a besoin ».

À l'intérieur du pod, j'avais les accès root.

La chaîne d'exploitation a tout de même échoué.

Même avec anyuid, SELinux a continué d'appliquer les restrictions du domaine container_t, empêchant les opérations sur les espaces de noms nécessaires pour poursuivre l'escalade. C'est l'aspect du modèle d'OpenShift qui, je pense, échappe souvent aux gens : les couches de sécurité se chevauchent intentionnellement. L'assouplissement d'un contrôle ne fait pas disparaître automatiquement le reste de la protection.

À ce stade, j'ai décidé de cesser d'être raisonnable.

J'ai créé une configuration délibérément dangereuse avec une SCC privilégiée, un utilisateur root et une fonctionnalité seccomp non confinée. Il s'agit de la configuration la plus permissive que l'on puisse réellement créer pour une charge de travail OpenShift sans livrer directement l'hôte.

Et enfin, les choses ont commencé à bouger.

Les espaces de noms d'utilisateurs ont fonctionné. unshare -U a réussi. La chaîne d'exploitation a commencé à progresser d'une manière impossible dans les scénarios précédents. Pour de nombreuses distributions Kubernetes, c'est à ce niveau que l'on passe de la « recherche sur la sécurité » à la « réponse aux incidents ».

Mais l'exploit a quand même échoué.

Fragnesia ne nécessite pas seulement la création d'espaces de noms. Elle nécessite un mappage UID/GID réussi à l'intérieur de l'espace de noms pour que l'attaquant puisse obtenir les capacités nécessaires pour accéder aux chemins réseau vulnérables.

Le système a bloqué cette dernière étape.

Même avec une SCC privilégiée, un utilisateur root et seccomp non confiné, SELinux a tout de même refusé les écritures vers /proc/self/uid_map. Sans un mappage UID réussi, la chaîne d'élévation des privilèges s'est effondrée. L'absence de privilèges root dans l'espace de noms signifiait l'absence d'accès XFRM/ESP. L'absence d'accès au sous-système signifiait l'absence de corruption du cache de pages.

Le noyau est resté vulnérable tout au long du processus, mais l'exploit a quand même échoué. Cette distinction est importante.

Ces tests ont renforcé une conviction que je nourris depuis longtemps : une bonne défense en profondeur reste précieuse, en particulier quand les choses tournent mal. Pas seulement lorsque tout est parfaitement configuré. Pas seulement lorsque toutes les charges de travail sont intègres et disposent des privilèges minimaux, et que les équipes de sécurité obtiennent tout ce qu'elles souhaitent. Les environnements réels sont complexes. Les contrôles s'assouplissent. Il existe des charges de travail héritées. Des compromis opérationnels surviennent constamment.

La question est de savoir si l'architecture tient toujours la route après certains de ces compromis.

Dans ce cas, c'était vrai.

Même après l'affaiblissement simultané de plusieurs couches de sécurité, SELinux a continué de traiter le conteneur comme fondamentalement non fiable et a empêché l'étape finale d'élévation des privilèges nécessaire à l'exploitation.

C'est toute la différence entre des « fonctions de sécurité » et une architecture de sécurité cohérente. Cette conversation plus large sur l'architecture m'importe davantage que la CVE Fragnesia elle-même. Si ces dernières semaines nous ont montré quelque chose, c'est que cette famille de vulnérabilités n'a probablement pas encore fini d'évoluer.

La question opérationnelle que les entreprises doivent commencer à se poser n'est plus : « Avons-nous corrigé la CVE-2026-46300 ? » La vraie question est la suivante : « Que se passe-t-il sur le plan opérationnel lorsque la CVE-2026-XXXXX apparaît mardi prochain en ciblant un autre sous-système que personne ne surveillait encore ? »

L'exploit évolue. Les signaux, eux, ne changent pas.

Et soyons honnêtes... à ce stade, cela n'a plus rien d'hypothétique.

C'est également là que Red Hat Advanced Cluster Security for Kubernetes apporte une valeur bien supérieure à une simple approche basée sur les CVE. Ce qui est intéressant avec Red Hat Advanced Cluster Security dans ce contexte, ce n'est pas qu'elle connaisse spécifiquement Fragnesia, mais que les schémas comportementaux entourant ces chaînes d'exploitation sont souvent reconnaissables, même lorsque la vulnérabilité exacte change.

Il est inhabituel qu'un conteneur d'applications Web crée soudainement des espaces de noms d'utilisateur. Il est inhabituel qu'une charge de travail d'application exécute /bin/su. Ces signaux restent pertinents, que l'exploit s'appelle Copy Fail, Dirty Frag, Fragnesia, DirtyDecrypt ou quel que soit le nom que les chercheurs inventeront la semaine prochaine.

La CVE change, mais dans ces cas-là, le comportement reste le même.

Cela compte, car le rythme des cycles de divulgation s'accélère, dépassant la capacité de nombreuses entreprises à appliquer des correctifs à de vastes parcs sans compromettre la stabilité opérationnelle. L'architecture et la visibilité comportementale vous permettent de gagner du temps. Parfois, ce délai représente la différence entre l'exécution d'un plan de remédiation contrôlé et 18 heures passées sur un pont d'incident à se demander quels clusters sont exposés.

Il en va de même au niveau opérationnel à l'échelle du parc.

Le test de trois pods dans un laboratoire est facile. La coordination des changements de politique sur des dizaines ou des centaines de clusters alors que les charges de travail de production restent en ligne est un défi totalement différent. C'est là que Red Hat Advanced Cluster Management for Kubernetes permet de passer d'une réaction désordonnée à un déploiement encadré. Au lieu d'auditer manuellement les clusters un par un, d'identifier manuellement les configurations dangereuses et de coordonner manuellement les changements de posture de sécurité entre les équipes, vous définissez une politique cohérente de manière centralisée et vous la propagez partout simultanément.

Cette distinction devient cruciale lorsque de nouvelles variantes apparaissent tous les deux ou trois jours.

Sur mon cluster Red Hat OpenShift on AWS (ROSA), le noyau est resté vulnérable pendant toute la durée des tests. Les sous-systèmes vulnérables sont restés présents. Les prérequis à l'exploitation existaient techniquement.

La chaîne d'exploitation a continué de s'effondrer car des contrôles multicouches ont interrompu l'escalade à plusieurs niveaux.

Ensuite, DirtyDecrypt a commencé à circuler publiquement alors que je rédigeais encore cet article.

Même philosophie d'exploitation plus large. Sous-système différent. Les mêmes défenses tiennent déjà bon.

Ce n'est pas de la chance. C'est une question d'architecture. C'est le principe de la défense en profondeur.

En savoir plus

• Quand l'IA trouve les bogues : Pourquoi la défense en profondeur a toujours été la solution
• Essayer OpenShift gratuitement
• En savoir plus sur OpenShift Platform Plus