Alerte sécurité Linux : Dirty Frag, l’exploit public plus dangereux que CopyFail qui menace Ubuntu, RHEL et Fedora

Dirty Frag vient de faire irruption dans l’actualité sécurité Linux avec un scénario que personne n’aime gérer, un exploit public, une élévation de privilèges vers root, et surtout aucun patch prêt à déployer. Le problème est présenté comme plus grave que CopyFail, non pas parce qu’il touche plus de machines sur le papier, mais parce qu’il arrive au pire moment, avec une divulgation qui a pris de vitesse la coordination habituelle.

Ce qui rend Dirty Frag particulièrement inquiétant, c’est sa nature “propre” pour un attaquant. On ne parle pas d’une course au timing ou d’un crash bruyant, mais d’un enchaînement de failles qui vise le page cache du noyau. Résultat, un utilisateur local non privilégié peut viser un accès root sur de nombreuses distributions, y compris des environnements récents utilisés en entreprise et dans le cloud.

Dirty Frag vise le noyau Linux via ESP et RxRPC

Dirty Frag désigne une chaîne de vulnérabilités d’élévation locale de privilèges dans le kernel Linux. Le principe est de combiner deux primitives d’écriture liées au page cache, l’une dans le sous-système xfrm-ESP associé à IPsec, l’autre dans RxRPC. L’attaquant ne démarre pas avec un accès distant magique, il lui faut déjà exécuter du code localement, par exemple via un compte compromis, une session conteneur mal cloisonnée, ou un service qui autorise l’exécution.

Le point central, c’est la capacité à modifier une mémoire adossée au cache de pages, alors que le noyau ne devrait pas permettre l’écriture sur des zones qui finissent par impacter des fichiers sensibles. Dans ce type d’attaque, l’objectif n’est pas “juste” de planter la machine, mais de corrompre des contenus de manière utile, jusqu’à obtenir une escalade de privilèges. Les chercheurs décrivent un mécanisme déterministe, donc plus prévisible qu’une exploitation basée sur une fenêtre de course.

Techniquement, l’exploitation s’appuie sur des chemins liés à des buffers adossés à des pages, avec des mécanismes de type splice() mentionnés dans les analyses. Pour un admin, ça compte, parce que ça signifie que la faille ne se limite pas à une configuration exotique. Elle vise des composants noyau présents dans l’écosystème depuis des années, et l’exploitation peut être enchaînée pour contourner certains garde-fous, selon la distribution et les modules chargés.

Sur le terrain, le risque typique ressemble à ça, un attaquant obtient un accès local “basique”, puis utilise Dirty Frag pour passer root presque immédiatement. Marc, ingénieur sécurité dans une ESN, résume la crainte côté exploitation, “quand tu as un PoC public et pas de correctif, tu passes en mode dégâts limités, pas en mode résolution propre”. C’est précisément ce qui distingue cette séquence, on parle d’urgence opérationnelle plus que de durcissement à moyen terme.

CopyFail ne suffit plus, Dirty Frag contourne des mitigations connues

Dirty Frag est présenté comme un successeur de CopyFail et, dans certains textes, comme “CopyFail2”. L’idée n’est pas de dire que CopyFail a disparu, au contraire, CopyFail a déjà eu le temps d’entrer dans les radars de défense avec une exploitation signalée “dans la nature” et un score CVSS 7,8 associé à ce précédent dossier. Dirty Frag arrive dans cette continuité, avec une logique d’exploitation proche, centrée sur des écritures via cache de pages.

La différence opérationnelle, c’est que Dirty Frag ne dépend pas des mêmes prérequis. Des administrateurs avaient appliqué une mitigation connue contre CopyFail, souvent décrite comme un blocage du module algif_aead. Problème, Dirty Frag peut être déclenché même si ce module n’est pas disponible. En clair, tu peux avoir “fait ce qu’il fallait” la semaine dernière, et découvrir que ça ne couvre pas la menace du jour.

Autre nuance importante, Dirty Frag est décrit comme une faille déterministe, donc avec un taux de réussite élevé et sans nécessité de course. Ça change la posture de risque. Dans une exploitation instable, tu peux parfois compter sur des échecs fréquents, des crashes, des signaux faibles. Ici, les descriptions insistent sur le fait que l’échec ne déclenche pas forcément de panique noyau, ce qui réduit les alertes involontaires. Pour un SOC, c’est une mauvaise nouvelle, moins d’indices bruyants.

Il faut aussi garder la tête froide, “plus grave” ne veut pas dire “tout Internet tombe”. Dirty Frag reste une LPE, donc un accélérateur d’attaque après un premier accès. Mais ce premier accès, dans la vraie vie, arrive vite, un mot de passe recyclé, une clé SSH exposée, un service web qui exécute une commande, ou un compte de support trop large. C’est pour ça que les équipes sécurité parlent de “chaînage”, Dirty Frag devient la brique qui transforme une intrusion limitée en prise de contrôle totale.

Ubuntu, RHEL et Fedora cités parmi les distributions touchées

Les listes de systèmes concernés mentionnent des distributions majeures, avec des versions récentes qui comptent en production. Sont cités Ubuntu 24.04.4, RHEL 10.1, Fedora 44, mais aussi openSUSE Tumbleweed, CentOS Stream 10 et AlmaLinux 10. Le message implicite est simple, ce n’est pas un bug d’une branche marginale, c’est un sujet qui traverse l’écosystème entreprise, cloud et poste de travail.

Une partie du risque vient de l’historique des composants. Le volet xfrm-ESP est associé à un commit de janvier 2017 mentionné dans les analyses, ce qui suggère une présence longue dans de nombreuses bases installées. Le second maillon, RxRPC, est lié à des ajouts plus récents, autour de 2023. Cette combinaison “ancien plus récent” complique la lecture, tu peux avoir un parc hétérogène où les conditions d’exploitation varient, mais la surface reste large.

Dans les environnements modernes, le point d’attention, ce sont les serveurs multi-utilisateurs, les bastions, les machines de CI, et les hôtes qui exécutent des workloads variés. Un exemple concret, une plateforme de build où des développeurs lancent des jobs non privilégiés. Si un compte est compromis, Dirty Frag peut transformer un accès limité en contrôle de l’hôte, puis en rebond vers d’autres segments. Dans un cloud privé, ça peut aussi toucher des nuds où plusieurs équipes cohabitent.

Marc, admin système dans une PME industrielle, décrit un cas classique, “on a des serveurs Ubuntu LTS pour la supervision et des VM RHEL pour l’ERP, l’attaquant n’a pas besoin d’un 0-day réseau si un compte interne saute”. Son point n’est pas théorique. Une LPE sur un serveur exposé n’est pas la même chose qu’une LPE sur une machine isolée, parce que les secrets, clés, tokens et accès NFS finissent par s’y accumuler. De ce fait, l’impact dépasse la machine compromise.

PoC public et divulgation bousculée, les correctifs manquent à l’appel

Le contexte de divulgation pèse lourd dans l’évaluation du risque. Dirty Frag a été signalé aux mainteneurs fin avril 2026, mais la séquence a été perturbée par une rupture d’embargo évoquée dans plusieurs récits. Résultat immédiat, un proof-of-concept public circule alors que les distributions n’ont pas encore de correctifs prêts. Pour les défenseurs, c’est le scénario “zéro filet”, on doit agir sans attendre un paquet sécurité.

Cette absence de patch ne signifie pas qu’il n’y aura jamais de correctif, mais qu’au moment où la menace s’installe, la réponse standard, patcher vite et partout, n’est pas disponible. C’est là que la comparaison avec CopyFail fait mal, CopyFail avait déjà déclenché une dynamique de correction et de mitigation. Dirty Frag arrive en décalage, avec un sentiment d’improvisation forcée. Les équipes doivent gérer la fenêtre la plus dangereuse, celle où l’attaque est documentée et la défense incomplète.

Les analyses insistent aussi sur la fiabilité. Dirty Frag appartient à une famille de bugs rapprochée de Dirty Pipe et de CopyFail, avec des logiques d’écriture via page cache. Pour un attaquant, la fiabilité est un multiplicateur, un exploit instable est coûteux et risqué, un exploit stable est industrialisable. Sur un parc de serveurs, ça peut se traduire par des tentatives automatisées après compromission, une fois un accès local obtenu via une autre faille ou un identifiant volé.

Nuance indispensable, tout le monde ne court pas le même danger dans l’heure. Une machine mono-utilisateur bien verrouillée n’a pas le même profil qu’un serveur partagé. Mais l’absence de patch et la présence d’un PoC imposent une posture défensive plus agressive, au moins temporairement. C’est aussi là qu’il faut être lucide, désactiver des composants noyau peut casser des usages légitimes, IPsec, certaines communications, ou des dépendances internes. La sécurité “à la hache” a un coût, et il faut le mesurer.

Désactiver des modules et purger le cache, les mitigations à court terme

Faute de correctifs, une approche de mitigation temporaire a été évoquée, désactiver les modules liés aux sous-systèmes concernés, notamment ESP et RxRPC, puis purger le page cache. Concrètement, ça revient à réduire la surface d’attaque en empêchant l’utilisation des interfaces vulnérables. C’est une réponse de crise, pas une solution élégante. Elle suppose d’identifier si ces modules sont chargés, utilisés, et si leur désactivation est acceptable.

Un exemple concret, une entreprise qui utilise IPsec pour des tunnels site-à-site peut dépendre d’ESP. Couper ce composant peut interrompre des flux critiques, supervision, sauvegardes, accès à des applications métiers. Dans ce cas, l’équipe peut choisir une stratégie intermédiaire, isoler les hôtes exposés, restreindre les accès locaux, réduire drastiquement les comptes pouvant se connecter, et renforcer la surveillance. L’objectif est de rendre l’accès local plus difficile, puisque Dirty Frag en dépend.

Autre cas, les serveurs de CI ou de data science où plusieurs utilisateurs lancent des tâches. Là, la mitigation peut passer par une réduction des droits, suppression des comptes inutiles, rotation de clés, durcissement de SSH, et segmentation réseau. Ça ne “corrige” pas la faille, mais ça réduit les chances qu’un attaquant obtienne le point d’entrée local. Marc, analyste réponse à incident, insiste sur un réflexe, “quand tu n’as pas de patch, tu travailles sur les prérequis d’attaque, accès local, persistance, et exfiltration”.

Il faut aussi prévoir la suite, dès que des patchs apparaissent, il faudra les déployer vite, mais proprement, en testant l’impact sur les noyaux, les modules, et les workloads. Une critique à formuler, la communication autour des mitigations peut donner une fausse impression de contrôle, “désactive et ça ira”. Non, ça dépend de l’usage réel des modules et de la capacité à contrôler l’accès local. Pour certains environnements, la mesure la plus réaliste sera d’augmenter la détection et de limiter l’exposition, en attendant une mise à jour noyau.