Le 25 juin 2026, les chercheurs de JFrog Security Research ont publié le premier exploit fonctionnel pour DirtyClone (CVE-2026-43503), une faille de sécurité permettant une élévation de privilèges en local sur Linux. N’importe quel utilisateur local non privilégié peut devenir root sur Debian, Ubuntu ou Fedora, en manipulant le cache de pages du noyau Linux. L’attaque est silencieuse et elle n’écrit rien sur le disque. Voici ce que l’on sait.

Zoom sur la faille CVE-2026-43503 alias DirtyClone

DirtyClone n’est pas une faille isolée. C’est la dernière variante en date de la famille DirtyFrag, une série de vulnérabilités du noyau Linux qui partagent toutes un point commun : de la mémoire adossée à un fichier sur disque (que l’on appelle le page cache) se retrouve traitée comme un tampon réseau modifiable. J’ai déjà documenté les failles précédentes, avec la faille Dirty Frag puis le contournement baptisé Fragnesia (CVE-2026-46300).

Le scénario d’attaque décrit par JFrog tient en quelques étapes. Voici comment un attaquant pourrait exploiter la faille DirtyClone.

Lorsque le noyau recopie un paquet réseau en interne, certaines fonctions oublient de reporter un petit flag de sécurité, en particulier celui qui signale que la mémoire du paquet est en réalité partagée avec un fichier du disque. Ce flag manquant montre la voie à suivre.

L’attaquant charge alors en mémoire un binaire privilégié comme , fait pointer le paquet réseau vers ces pages mémoire, puis force le noyau à le cloner. Le paquet cloné traverse un tunnel IPsec que l’attaquant contrôle de bout en bout (car il l’aura mis en place sur la boucle locale), et l’étape de déchiffrement vient réécrire, au passage, les contrôles d’authentification du binaire avec des octets choisis par l’attaquant. Cette modification permet l’élévation de privilèges en elle-même puisque la prochaine fois que sera lancé, cela donnera accès à une session root.

Le tunnel IPsec monté en local est une condition indispensable pour que cette faille soit exploitable. Toutefois, configurer ce tunnel IPsec local nécessite la capacité . L’exploitation dépend donc de la configuration du système (nous y reviendrons par la suite).

“Le TEE est essentiel : il duplique les paquets sortants au sein du noyau. En interne, cela déclenche la fonction nf_dup_ipv4, ce qui entraîne le clonage du SKB via la fonction __pskb_copy_fclone().”, précisent les chercheurs.

Il est important de préciser que le flag est la rustine introduite par le correctif DirtyFrag publié en mai 2026. Le problème, et c’est ce qui permet l’exploitation de DirtyClone, c’est qu’il peut être “perdu” au fil des fonctions qui manipulent les fragments de paquets. Fragnesia exploitait sa disparition lors d’une opération de fusion, tandis que DirtyClone fait de même lors du clonage.

À juste titre, les chercheurs de JFrog mettent en évidence les liens entre ces trois vulnérabilités.

L’attaque DirtyClone ne laisse pas de trace évidente. En effet, le fichier sur le disque ne bouge pas d’un octet. La modification n’est visible que dans la copie en mémoire du noyau : les outils d’intégrité de fichiers n’y voient rien, l’attaque ne laisse aucune trace dans les journaux, et un simple redémarrage restaure le binaire d’origine. D’ici là, l’attaquant sera déjà root depuis longtemps….

Debian, Ubuntu, Fedora concernés : qui doit patcher, et comment

D’après JFrog, l’attaque a été confirmée sur les distributions où les user namespaces non privilégiés sont activés. Ce qui impacterait, à minima :

• Debian et Fedora : vulnérables dans leur configuration par défaut,
• Ubuntu 24.04 et versions ultérieures : partiellement atténués via les restrictions AppArmor sur les namespaces, mais tout de même considérés comme affectés,
• Environnements cloud et conteneurs : clusters Kubernetes, hébergements multi-tenants et ressources conteneurisées figurent parmi les cibles les plus exposées, dès lors qu’un utilisateur local peut obtenir la capacité (souvent accessible via les user namespaces).

L’occasion de vous glisser notre article à propos des principaux risques de sécurité liés aux conteneurs Docker.

Ce qu’il faut comprendre également, c’est qu’un système n’est totalement protégé qu’une fois toute la chaîne de correctifs DirtyFrag appliquée (CVE-2026-43284, CVE-2026-43500, CVE-2026-46300 puis CVE-2026-43503). Un noyau qui n’aurait reçu que les premiers patchs reste vulnérable à ce nouveau contournement.

Le mieux, c’est de mettre à jour le noyau Linux vers une version patchée ou d’appliquer le correctif rétroporté par sa distribution. Il est à noter que le correctif a été introduit pour la première fois dans la version v7.1-rc5 publiée le 24 mai 2026. Vous pouvez vérifier la version du noyau avec et la comparer à la version corrigée publiée par votre distribution.

Dans le cas où ce n’est pas possible, voici les recommandations des chercheurs de JFrog pour protéger les machines Linux :

• Bloquer l’obtention de en positionnant ,
• Blacklister les modules , et si IPsec n’est pas utilisé.

Si l’on regarde du côté de Debian, le correctif de sécurité pour la CVE-2026-43503 a été introduit dans la version 6.12.94-1 publiée dans le dépôt de mises à jour de sécurité pour Debian 13 Trixie.

À ce jour, aucune exploitation active dans la nature n’aurait été repérée pour DirtyClone, et JFrog indique avoir conservé son code d’exploitation complet. Attention tout de même, car les détails et la démonstration visibles dans le rapport publié par les chercheurs offrent de nombreux détails qu’un attaquant pourrait utiliser pour tenter de reproduire l’attaque.