Fragnesia (CVE-2026-46300) - Faille de sécurité Linux du type Dirty Frag

Dans le cadre de notre veille sécurité, nous signalons Fragnesia, suivie sous l’identifiant CVE-2026-46300.

Le sujet est à traiter sérieusement: Fragnesia est une faille Linux locale d’élévation de privilèges. Elle ne donne pas directement un accès distant à un serveur exposé sur Internet, mais elle peut devenir critique dès qu’un attaquant dispose déjà d’une exécution locale, même limitée.

La vulnérabilité se situe dans le voisinage technique de DirtyFrag: noyau Linux, page cache, splice(), structures réseau et traitements en place dans les chemins XFRM/ESP. Autrement dit, on reste dans cette famille de bugs où le fichier sur disque peut rester intact alors que sa représentation en mémoire est altérée.

Au 14 mai 2026, les pages de suivi distribution commencent à se remplir. Ubuntu classe la CVE en priorité High et la décrit comme une élévation locale triviale. Debian liste plusieurs branches du paquet linux comme vulnérables ou non encore corrigées. Red Hat dispose également d’une page CVE dédiée à CVE-2026-46300.

Pourquoi Fragnesia doit être surveillée de près

Fragnesia arrive très peu de temps après notre article sur DirtyFrag, lui-même publié quelques jours après Copy Fail.

Ce rythme est important pour les équipes d’exploitation. On ne parle pas d’une vulnérabilité isolée, mais d’une série de failles autour de mécanismes noyau optimisés:

• manipulation de pages mémoire;
• traitement de données en place;
• chemins réseau et cryptographiques;
• interactions avec le page cache;
• hypothèses fines sur la propriété réelle des fragments mémoire.

Quand ces hypothèses cassent, l’impact peut être disproportionné: un utilisateur non privilégié peut modifier ce que le noyau sert depuis le cache, sans forcément modifier immédiatement le fichier sur disque.

Pour les contrôles d’intégrité classiques, c’est une mauvaise nouvelle. Un hash calculé sur le fichier présent sur disque peut rester propre alors que le comportement observé à l’exécution ne l’est plus.

Le lien avec DirtyFrag et Copy Fail

Dans notre article sur Copy Fail, nous expliquions déjà le risque des écritures inattendues dans le page cache.

Avec DirtyFrag, le sujet s’est déplacé vers des chemins réseau du noyau, notamment xfrm-ESP et rxrpc. Fragnesia reste dans cette zone: elle concerne le traitement XFRM ESP-in-TCP et un problème de conservation d’information sur des fragments partagés lors de certaines opérations de coalescence de paquets.

La lecture opérationnelle est simple: si vous avez déjà traité DirtyFrag uniquement comme un incident ponctuel, Fragnesia montre qu’il faut suivre toute la famille de bugs, pas seulement un correctif précis.

Un correctif initial peut fermer une porte tout en révélant une autre hypothèse fragile dans le même sous-système. C’est exactement le genre de situation où la veille CVE, les bulletins distribution et les tests post-patch comptent autant que la commande de mitigation elle-même.

Les environnements Linux les plus exposés

Fragnesia est locale, mais “locale” ne veut pas dire “secondaire”.

À prioriser:

• hôtes Linux multi-utilisateurs;
• noeuds Kubernetes;
• runners CI/CD et serveurs de build;
• plateformes qui exécutent du code client ou utilisateur;
• bastions et machines d’administration partagées;
• postes développeurs avec beaucoup d’outillage local;
• serveurs applicatifs déjà exposés à un risque de compromission initiale.

Dans un environnement moderne, un accès local peut venir de beaucoup de chemins: une application web compromise, un job CI malveillant, un conteneur trop permissif, un compte SSH volé ou un outil interne vulnérable.

La bonne question n’est donc pas seulement “l’attaquant est-il déjà sur la machine ?”. C’est plutôt: si un processus non privilégié tourne sur cet hôte, que peut-il devenir ?

Mitigation immédiate à envisager

La mitigation évoquée par Ubuntu renvoie à la même logique que DirtyFrag: bloquer les modules concernés si votre contexte le permet.

Commande de mitigation, à valider avant déploiement large:

sh -c "printf 'install esp4 /bin/false\ninstall esp6 /bin/false\ninstall rxrpc /bin/false\n' > /etc/modprobe.d/fragnesia.conf; rmmod esp4 esp6 rxrpc 2>/dev/null; true"

Cette commande empêche le chargement de esp4, esp6 et rxrpc, puis tente de décharger les modules déjà présents.

Attention: esp4 et esp6 peuvent être nécessaires à des usages IPsec/ESP, notamment certains VPN ou tunnels d’infrastructure. rxrpc est plus rare sur des serveurs classiques, mais peut être utilisé dans des environnements spécifiques.

Avant de pousser cette mitigation partout, il faut donc vérifier:

• présence de VPN IPsec ou d’usages ESP;
• dépendances réseau particulières;
• criticité des machines;
• capacité à redémarrer rapidement si un module reste chargé;
• existence d’un correctif noyau déjà disponible côté distribution.

Sur les systèmes suspects ou très exposés, un vidage du page cache peut aussi être envisagé après mitigation:

sh -c "echo 3 > /proc/sys/vm/drop_caches"

Ce geste ne remplace pas une investigation. Si une exploitation a réussi, il faut considérer l’hôte comme compromis et chercher une persistance plus durable que la simple modification du cache.

Patcher reste la vraie remédiation

La mitigation réduit l’exposition immédiate. Elle ne remplace pas un noyau corrigé.

La trajectoire saine est la suivante:

1. identifier les distributions, versions de noyau et profils d’hôtes concernés;
2. qualifier les usages de esp4, esp6, rxrpc et IPsec;
3. appliquer une mitigation ciblée si le correctif n’est pas encore disponible;
4. suivre les bulletins Debian, Ubuntu, Red Hat et de vos distributions réelles;
5. installer le noyau corrigé dès disponibilité;
6. redémarrer sur le bon noyau, puis vérifier la version effectivement chargée.

Sur Linux, le piège classique est de confondre “paquet installé” et “noyau effectivement en cours d’exécution”. Après mise à jour, il faut vérifier ce que la machine utilise réellement.

Commande utile:

uname -a

Selon votre distribution, complétez avec les outils de suivi de paquets et les avis de sécurité officiels.

Détection: ne pas se limiter aux hashes disque

Comme Copy Fail et DirtyFrag, Fragnesia touche une zone où les contrôles limités au disque peuvent être insuffisants.

Signaux à surveiller, selon vos outils:

• création inattendue de namespaces utilisateur ou réseau;
• activité NETLINK_XFRM depuis des processus qui n’ont rien à voir avec du VPN;
• chargement ou usage inhabituel de esp4, esp6 ou rxrpc;
• usages atypiques de splice() depuis des fichiers vers des sockets;
• exécution locale non prévue sur des hôtes critiques.

Pris séparément, ces signaux ne sont pas forcément malveillants. Leur combinaison, surtout sur des environnements multi-tenant ou CI/CD, mérite une qualification rapide.

Notre lecture opérationnelle

Fragnesia confirme une tendance déjà visible avec Copy Fail et DirtyFrag: les vulnérabilités locales Linux autour du page cache et des chemins optimisés du noyau doivent être prises au sérieux.

Elles ne remplacent pas les vulnérabilités distantes dans la gestion des priorités, mais elles changent fortement le niveau de risque après un premier point d’appui. Pour une infrastructure qui héberge des workloads variés, des conteneurs, des runners ou des accès administratifs partagés, c’est exactement le type de faille qui peut transformer un incident limité en compromission complète de l’hôte.

Chez Forget About IT, ce type d’alerte entre dans une réponse structurée:

• veille CVE et bulletins distributions;
• qualification de l’exposition réelle;
• mitigation si elle ne casse pas un usage critique;
• patch management;
• redémarrage contrôlé;
• vérification post-intervention.

La réponse doit être rapide, mais pas aveugle. Désactiver ESP sur un serveur qui porte un VPN IPsec peut créer un incident de production. Ne rien faire sur un runner CI multi-tenant peut en créer un autre.

Conclusion

Fragnesia (CVE-2026-46300) est une nouvelle faille Linux locale à suivre de près, surtout parce qu’elle s’inscrit dans la continuité de DirtyFrag et de Copy Fail.

Le bon réflexe:

• prioriser les hôtes multi-utilisateurs, CI/CD, conteneurs et bastions;
• vérifier les bulletins de votre distribution;
• appliquer la mitigation esp4 / esp6 / rxrpc si elle est compatible avec vos usages;
• patcher le noyau dès qu’un correctif validé est disponible;
• redémarrer et vérifier le noyau réellement chargé.

Si vous avez besoin d’aide pour qualifier l’exposition ou organiser la mitigation sur vos serveurs Linux, nous pouvons vous accompagner dans le cadre de notre infogérance.

• Découvrir notre infogérance
• Nous contacter

Sources

• Debian Security Tracker - CVE-2026-46300
• Ubuntu Security - CVE-2026-46300
• Red Hat CVE Database - CVE-2026-46300

FAQ: Fragnesia et CVE-2026-46300

Qu’est-ce que Fragnesia, ou CVE-2026-46300 ?

Fragnesia est une vulnérabilité locale du noyau Linux pouvant permettre une élévation de privilèges vers root via une modification du page cache dans des chemins XFRM/ESP.

Fragnesia est-elle liée à DirtyFrag ?

Oui. Elle se situe dans la même famille de problèmes autour du page cache, de XFRM/ESP et des traitements en place. Elle doit donc être suivie même si une première mitigation DirtyFrag a déjà été étudiée.

L’attaque est-elle distante ?

Non. Il s’agit d’une élévation de privilèges locale: l’attaquant doit déjà pouvoir exécuter du code sur l’hôte ou dans un contexte lui donnant un point d’appui local.

Quels environnements faut-il prioriser ?

Les environnements multi-utilisateurs, Kubernetes, runners CI/CD, bastions, postes développeurs et plateformes exécutant du code non totalement maîtrisé doivent être qualifiés en priorité.

Quelle remédiation appliquer ?

La réponse durable reste l’installation d’un noyau corrigé par la distribution. En attendant, la mitigation proche de DirtyFrag consiste à bloquer esp4, esp6 et rxrpc si cela ne casse pas d’usage légitime comme IPsec.