RefluXFS (CVE-2026-64600) : une faille XFS peut donner un accès root

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

Cette vulnérabilité touche le chemin copy-on-write du système de fichiers XFS dans le noyau Linux. Un utilisateur local non privilégié peut exploiter une condition de concurrence pour altérer sur disque un fichier qu’il peut lire, y compris un fichier appartenant à root, puis transformer cette écriture en élévation de privilèges vers root.

Le changement peut persister après redémarrage, ne modifie pas nécessairement les métadonnées du fichier ciblé et ne produit pas de message dans les journaux du noyau lors des tests publiés par Qualys. C’est ce qui rend RefluXFS particulièrement sérieuse : l’exploitation agit au niveau des blocs du système de fichiers et laisse peu de signaux évidents.

La faille a été divulguée publiquement le 22 juillet 2026. Le correctif amont a été intégré le 16 juillet 2026 et des noyaux corrigés sont déjà distribués ou en cours de rétroportage selon les éditeurs.

Pourquoi RefluXFS mérite une réaction rapide

RefluXFS n’est pas une porte d’entrée distante. Elle ne permet pas, seule, à n’importe quel internaute de devenir root sur un serveur.

Elle devient en revanche critique dès qu’un attaquant dispose déjà d’un point d’appui local :

• compte utilisateur compromis ;
• shell obtenu via une application vulnérable ;
• job CI/CD malveillant ;
• poste développeur ou bastion partagé ;
• plateforme multi-utilisateur ;
• workload non fiable exécuté sur un hôte Linux.

La primitive décrite par Qualys permet d’écraser le contenu de fichiers protégés lisibles sur le même volume XFS. Le PoC public vise notamment /etc/passwd ou des binaires SUID-root. Les modifications sont écrites sur disque, survivent au redémarrage et peuvent conserver les attributs du fichier ciblé.

Les mécanismes habituels de durcissement ne constituent pas une réponse suffisante. Selon les tests publiés, SELinux en mode Enforcing, les protections mémoire du noyau, les restrictions de namespaces et les limites de capacités des conteneurs ne bloquent pas de manière fiable ce chemin d’exploitation.

Une nouvelle faille locale dans une série déjà longue

RefluXFS arrive après plusieurs vulnérabilités Linux locales récentes que nous avons déjà détaillées.

Copy Fail, ou CVE-2026-31431, permettait elle aussi de transformer un accès local limité en root en abusant d’écritures inattendues dans le page cache.

DirtyClone, ou CVE-2026-43503, prolongeait la famille DirtyFrag autour des fragments réseau partagés et des copies en mémoire de fichiers.

GhostLock, ou CVE-2026-43499, touchait un autre sous-système du noyau, rtmutex et futex PI, mais avec la même conséquence opérationnelle : un processus local non privilégié pouvait viser le contrôle complet de l’hôte.

RefluXFS n’emprunte pas les mêmes chemins techniques. Ici, le problème se situe dans XFS, avec une écriture directe sur disque. Le point commun reste néanmoins important pour l’exploitation : une faille applicative ou un accès utilisateur limité ne doit jamais être considéré isolément des élévations de privilèges disponibles sur le noyau chargé.

Ce qui casse dans XFS

XFS prend en charge les reflinks, une fonction de clonage rapide de fichiers basée sur le copy-on-write.

Lorsqu’un fichier est cloné par reflink, les deux fichiers partagent d’abord les mêmes blocs physiques. Si l’un des fichiers est modifié, XFS doit normalement allouer un bloc privé au fichier modifié avant d’y écrire. Le fichier d’origine reste ainsi intact.

RefluXFS exploite une condition de concurrence entre plusieurs écritures O_DIRECT sur le fichier cloné.

Dans le chemin vulnérable :

1. XFS relève la correspondance entre le fichier et ses blocs physiques ;
2. le noyau relâche temporairement un verrou d’inode pour obtenir de l’espace dans le journal de transactions ;
3. une autre écriture termine entre-temps son propre cycle copy-on-write et modifie cette correspondance ;
4. la première écriture reprend avec une adresse physique devenue obsolète ;
5. XFS conclut à tort que le bloc n’est plus partagé ;
6. l’écriture directe atteint le bloc qui appartient encore au fichier d’origine.

Le correctif force XFS à relire la correspondance du fichier après le cycle de verrouillage lorsque le compteur de séquence a changé. Il empêche ainsi une écriture direct I/O de continuer avec une information devenue obsolète.

Conditions d’exposition

Un système est exposé si les trois conditions suivantes sont réunies :

1. le noyau chargé est un Linux 4.11 ou ultérieur qui ne contient pas le correctif ;
2. un volume XFS a été créé avec reflink=1 ;
3. ce volume contient à la fois un fichier sensible lisible et un répertoire dans lequel l’utilisateur non privilégié peut écrire.

La troisième condition est très courante sur une installation avec un seul volume racine : /etc et /usr/bin contiennent des cibles sensibles, tandis que /var/tmp est accessible en écriture aux utilisateurs.

La prise en charge vulnérable a été introduite dans Linux 4.11 en 2017. Le support reflink=1 est devenu le comportement par défaut de mkfs.xfs à partir de 2019, ce qui explique la large fenêtre d’exposition.

Important : reflink est une caractéristique enregistrée dans le superbloc lors de la création du système de fichiers. Ce n’est pas une option que l’on peut désactiver temporairement au montage.

Distributions et environnements à qualifier

Les installations par défaut suivantes sont citées comme particulièrement concernées lorsqu’elles utilisent un noyau non corrigé :

• RHEL 8, 9 et 10 ;
• CentOS Stream 8, 9 et 10 ;
• Rocky Linux et AlmaLinux 8, 9 et 10 ;
• Oracle Linux 8, 9 et 10 ;
• CloudLinux 8, 9 et 10 ;
• Fedora Server 31 et versions ultérieures ;
• Amazon Linux 2023 ;
• certaines images Amazon Linux 2 publiées depuis décembre 2022.

Debian, Ubuntu, Fedora Workstation, SLES, openSUSE et Arch n’utilisent généralement pas XFS comme système de fichiers racine par défaut. Ils peuvent néanmoins être vulnérables si XFS a été choisi manuellement et si le volume a été créé avec les reflinks actifs.

RHEL et CentOS 7 ne sont pas concernés par ce scénario : leur noyau 3.10 et leurs outils XFS précèdent la prise en charge des reflinks visée par RefluXFS.

Il ne faut pas conclure à partir du seul nom de la distribution. La décision doit croiser le noyau réellement chargé, le format du volume et le bulletin du fournisseur. Les distributions rétroportent régulièrement des correctifs sans adopter le numéro de version du noyau amont.

Vérifier l’exposition sans exécuter le PoC

Le PoC RefluXFS cherche volontairement à altérer un fichier protégé. Il ne doit pas servir de test de conformité sur une machine de production.

Commencez par relever le noyau réellement chargé :

uname -r

Inventoriez les volumes XFS montés :

findmnt -t xfs -o TARGET,SOURCE,FSTYPE,OPTIONS

Sur le volume racine, vérifiez la présence de reflink=1 :

xfs_info / | grep -E 'reflink='

Répétez xfs_info avec chaque point de montage XFS identifié. Si la commande affiche reflink=1, le volume remplit la condition liée au système de fichiers. Si / n’est pas en XFS, la machine n’est pas exposée par son volume racine, mais un autre volume XFS peut rester concerné.

Sur les distributions RPM, relevez également les paquets noyau installés :

rpm -qa | grep -E '^kernel|^kernel-core' | sort

Sur Debian ou Ubuntu :

dpkg -l 'linux-image*' | awk '/^ii/ {print $2, $3}'

Ces commandes qualifient la configuration ; elles ne prouvent pas à elles seules que le correctif est présent. Comparez le résultat à l’avis de sécurité de la distribution et à son changelog de paquet.

Au 24 juillet 2026, le NVD indique comme corrigées les branches amont 6.12.96, 6.18.39, 7.1.4 et 7.2-rc4. Ce tableau amont ne remplace pas les versions corrigées publiées par chaque distribution.

Mitigation provisoire : pas de contournement fiable

Contrairement à certaines failles noyau pour lesquelles un module peut être bloqué ou un paramètre sysctl durci, les sources publiques ne proposent ici aucune mitigation temporaire fiable et pratique.

Il ne faut notamment pas considérer comme une protection suffisante :

• SELinux en mode Enforcing ;
• KASLR, SMEP, SMAP ou le kernel lockdown ;
• les restrictions de namespaces utilisateur ;
• les limites de capacités d’un conteneur ;
• un profil seccomp courant ;
• la surveillance des seuls journaux du noyau ;
• une tentative de désactivation de reflink au montage.

Réduire provisoirement les accès shell, déplacer les workloads non fiables ou isoler les hôtes multi-utilisateurs peut diminuer la probabilité d’exploitation pendant la maintenance. Cela ne corrige pas la faille et ne transforme pas un noyau vulnérable en noyau sûr.

Reformater ou migrer un volume sans reflink serait une opération lourde et risquée, pas une mitigation d’urgence raisonnable lorsque des noyaux corrigés existent.

Remédiation : noyau corrigé et redémarrage complet

La réponse fiable est directe :

1. inventorier les hôtes avec des volumes XFS ;
2. vérifier reflink=1 sur chaque volume ;
3. identifier le noyau réellement chargé ;
4. consulter l’avis de sécurité de la distribution ;
5. installer le paquet noyau corrigé fourni par l’éditeur ;
6. effectuer un redémarrage complet ;
7. vérifier le noyau chargé après redémarrage ;
8. conserver la preuve de correction.

Après la maintenance :

uname -r

Il faut ensuite comparer ce résultat à la version corrigée annoncée par la distribution. La présence d’un paquet récent sur disque ne suffit pas : tant que l’ancien noyau reste chargé, l’hôte reste exposé.

Qualys indique qu’un livepatch ne constitue pas ici une réponse fiable et recommande le correctif noyau suivi d’un redémarrage complet.

Si une exploitation est suspectée

Une absence d’alerte dans dmesg ne permet pas d’écarter RefluXFS. L’écriture publiée agit au niveau des blocs, sans journal noyau et sans modification nécessaire de l’inode ciblé.

Si un hôte vulnérable a exécuté du code non fiable ou présente des signes de compromission :

• considérez l’hôte comme potentiellement compromis ;
• recherchez les changements de contenu dans les fichiers sensibles, pas seulement leurs métadonnées ;
• vérifiez les comptes locaux, clés SSH, fichiers sudoers et binaires SUID ;
• analysez les processus, mécanismes de persistance et mouvements latéraux ;
• faites tourner les secrets et identifiants accessibles depuis l’hôte ;
• privilégiez une reconstruction maîtrisée si l’intégrité ne peut plus être établie.

Un simple redémarrage ne remet pas un fichier altéré dans son état initial : contrairement à plusieurs attaques limitées au page cache, l’écriture RefluXFS persiste sur disque.

Notre lecture opérationnelle

RefluXFS concerne particulièrement les distributions d’entreprise qui ont fait de XFS leur choix par défaut. La vulnérabilité est locale, mais son exploitation est présentée comme fiable et son résultat est persistant.

La bonne réponse n’est donc pas de lancer un PoC sur le parc. Elle consiste à construire rapidement une vue fiable :

• quels hôtes exécutent un noyau potentiellement vulnérable ;
• quels volumes utilisent XFS avec reflink=1 ;
• où du code ou des comptes non privilégiés peuvent s’exécuter ;
• quels correctifs sont disponibles chez les distributions réelles ;
• quelles machines ont effectivement redémarré sur le noyau corrigé.

C’est exactement le rôle d’une veille CVE quotidienne intégrée à l’exploitation : transformer une alerte noyau en inventaire, priorisation, maintenance et preuve de remédiation.

Chez Forget About IT, ce type d’alerte entre dans le maintien en condition de sécurité : qualification du parc, préparation du correctif, redémarrage contrôlé, vérification post-intervention et investigation si l’intégrité est mise en doute.

Conclusion

RefluXFS (CVE-2026-64600) est une élévation de privilèges locale sérieuse dans XFS. Sur un noyau non corrigé et un volume reflink=1, un utilisateur non privilégié peut altérer sur disque un fichier protégé et obtenir root.

Le bon réflexe :

• inventorier immédiatement les volumes XFS ;
• vérifier reflink=1 sans exécuter le PoC ;
• comparer le noyau chargé au bulletin de la distribution ;
• installer le noyau corrigé ;
• redémarrer complètement l’hôte ;
• vérifier et documenter la version réellement chargée.

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

• Découvrir notre infogérance
• Nous contacter
• Prendre rendez-vous

Sources

• Qualys Threat Research Unit - RefluXFS: A Linux Kernel Local Privilege Escalation to Root in XFS
• oss-sec - RefluXFS: LPE in the Linux kernel via XFS reflink race
• NVD - CVE-2026-64600
• Linux kernel - correctif xfs: resample the data fork mapping after cycling ILOCK
• Debian Security Tracker - CVE-2026-64600
• Ubuntu Security - CVE-2026-64600
• SOC Prime - CVE-2026-64600: RefluXFS Linux Kernel Flaw

FAQ : RefluXFS et CVE-2026-64600

Qu’est-ce que RefluXFS ?

RefluXFS est une condition de concurrence dans le chemin copy-on-write de XFS. Elle permet à un utilisateur local non privilégié d’écraser sur disque le contenu de fichiers lisibles sur un volume XFS vulnérable, puis d’obtenir root.

L’attaque est-elle distante ?

Non. L’attaquant doit déjà pouvoir exécuter du code localement. RefluXFS sert ensuite d’élévation de privilèges vers le contrôle complet de l’hôte.

Quels systèmes sont vulnérables ?

Il faut réunir un noyau Linux 4.11 ou ultérieur sans le correctif, un volume XFS créé avec reflink=1, ainsi qu’un fichier sensible et un répertoire accessible en écriture à l’utilisateur sur le même système de fichiers.

Existe-t-il une mitigation temporaire ?

Les sources publiques ne donnent pas de contournement fiable. Reflink ne peut pas être désactivé par une option de montage après création du volume, et les mécanismes de durcissement courants ne bloquent pas le chemin vulnérable. Il faut installer le noyau corrigé puis redémarrer.

Comment vérifier l’exposition ?

Relevez le noyau chargé avec uname -r, inventoriez les volumes XFS avec findmnt, puis vérifiez reflink=1 avec xfs_info. Comparez enfin le paquet noyau à l’avis de sécurité de votre distribution.