RefluXFS est le nom donné à une faille du noyau Linux qui transforme un banal compte local en tremplin vers root. Référencée CVE-2026-64600, elle touche le chemin copy-on-write de XFS et permet de réécrire sur disque le contenu d’un fichier lisible, malgré ses droits Unix. Le correctif est déjà intégré en amont, mais les noyaux distribués doivent encore être installés puis redémarrés.
Le sujet n’est pas théorique : Qualys a publié un exploit fonctionnel et l’a testé sur une installation RHEL 10.2 par défaut. La faille est locale, pas exploitable directement depuis Internet, mais un accès utilisateur obtenu par une autre faiblesse suffit ensuite à prendre la machine. Et comme la modification se fait au niveau des blocs, les journaux habituels peuvent rester parfaitement muets.
Une course minuscule, un impact énorme
XFS propose une fonction appelée reflink. Elle permet de cloner un fichier presque instantanément en faisant pointer deux fichiers vers les mêmes blocs physiques. Tant que personne n’écrit, tout va bien. Lorsqu’une écriture arrive, le système doit normalement créer une copie privée, déplacer la référence du fichier modifié et diminuer le compteur de partage de l’ancien bloc.
RefluXFS exploite une fenêtre de concurrence dans cette mécanique. Pour réserver de l’espace et éviter un interblocage, le noyau relâche brièvement le verrou de l’inode. Une autre écriture peut alors terminer sa propre opération copy-on-write et remapper le fichier vers un nouveau bloc. Quand la première écriture reprend, elle vérifie encore l’ancien emplacement physique, avec une information devenue périmée, puis croit à tort que ce bloc est privé.
La suite est particulièrement vilaine : une écriture directe, via O_DIRECT, peut alors atterrir dans le bloc qui appartient toujours au fichier source. L’attaquant ne modifie donc pas seulement sa copie de travail ; il altère le fichier original. Les permissions, le propriétaire, la taille et les dates peuvent rester inchangés, ce qui donne à la corruption un camouflage assez efficace.
Qui doit vraiment s’inquiéter
Les trois conditions sont précises. Il faut un noyau 4.11 ou plus récent qui ne contient pas le correctif, un système de fichiers XFS créé avec reflink=1, et sur ce même volume un fichier lisible à forte valeur ainsi qu’un répertoire où l’utilisateur peut écrire. Un fichier système appartenant à root et /var/tmp sur le volume racine suffisent à réunir le dernier ingrédient.
Les distributions de la famille Red Hat sont les plus exposées dans leur configuration habituelle : RHEL 8 à 10, CentOS Stream, Rocky Linux, AlmaLinux, Oracle Linux, CloudLinux et Fedora Server sont citées par Qualys. Amazon Linux 2023 est aussi concerné, comme certaines images Amazon Linux 2 publiées depuis décembre 2022.
Debian, Ubuntu, SUSE, openSUSE, Arch Linux et Fedora Workstation ne choisissent généralement pas XFS pour la racine. Cela ne les rend pas magiquement immunes : une installation personnalisée avec XFS et reflink activé peut entrer dans le périmètre. Le suivi Debian indique d’ailleurs que trixie est corrigée en 6.12.96-1, tandis que plusieurs versions restent marquées vulnérables.
Le visuel ci-dessous, publié par Qualys avec son analyse, résume le type de corruption obtenu pendant la démonstration : une écriture censée rester dans la copie reflinkée finit par atteindre le fichier protégé. Ce n’est pas une capture d’écran du système de fichiers de ton serveur, mais le document technique de la source qui accompagne la preuve de concept.
Crédit : Qualys, « RefluXFS : A Linux Kernel Local Privilege Escalation to Root in XFS », https://blog.qualys.com/vulnerabilities-threat-research/2026/07/22/refluxfs-a-linux-kernel-local-privilege-escalation-to-root-in-xfs-cve-2026-64600
Le correctif existe, le bricolage beaucoup moins
Le correctif amont est le commit 2f4acd0, intitulé « xfs: resample the data fork mapping after cycling ILOCK ». En clair, le noyau vérifie si la cartographie du fichier a changé pendant la libération du verrou et relit la bonne information avant de poursuivre. Le commit a été intégré à la branche principale le 16 juillet, avant la publication coordonnée du 22 juillet.
CVE-2026-64600 porte un score CVSS 3.1 de 7,8, avec un vecteur local nécessitant déjà un compte, mais sans interaction utilisateur. NVD reprend la description de kernel.org ; Ubuntu classe encore plusieurs séries en « évaluation nécessaire », et Debian publie ses versions corrigées pour trixie et unstable. Il faut donc regarder l’avis de ta distribution, pas seulement le numéro du noyau amont.
La vérification la plus utile concerne le volume : xfs_info / | grep reflink= permet de voir si la racine annonce reflink=1. Répète la commande sur les autres volumes XFS. Ensuite, installe les mises à jour de sécurité du fournisseur et redémarre. Désactiver SELinux, compter sur le confinement d’un conteneur ou ajouter une règle de surveillance ne constitue pas un correctif fiable : la primitive passe par l’allocation des blocs et contourne précisément ces couches.
Le détail qui change la réponse incident
Qualys indique que son exploit modifie un fichier sur disque sans produire de message dans dmesg et que le résultat survit au redémarrage. Une machine vulnérable ne doit donc pas être considérée comme saine simplement parce que ses journaux sont propres. Si un hôte XFS était accessible à un compte compromis, il faut conserver les éléments forensiques, vérifier les fichiers sensibles et envisager une reconstruction depuis une source de confiance après rotation des secrets.
Pour les environnements multi-utilisateurs, la priorité est de réduire la fenêtre : correctif du noyau, redémarrage, inventaire des volumes XFS et revue des comptes locaux. Les hôtes exposés à des utilisateurs externes, à des chaînes de compilation ou à des services d’exécution partagée méritent le premier créneau. Le scénario reste local, mais « local » ne veut pas dire « anodin » quand un compte de service traîne dans la machine depuis six mois.
Un correctif plus intéressant que le buzz IA
La découverte a aussi une dimension inhabituelle : Qualys explique avoir utilisé Claude Mythos Preview pour guider une recherche de course critique dans le noyau, puis avoir revu, reproduit et validé chaque résultat avec ses chercheurs. Le modèle a accéléré l’exploration ; il n’a pas remplacé la preuve, la divulgation coordonnée ni le travail des mainteneurs XFS.
C’est la nuance à retenir. Une IA peut trouver une piste crédible dans un code immense, mais la sécurité se joue encore dans la reproduction, le tri des conditions d’exploitation et la qualité du correctif. Sinon, on ne fait pas de la recherche assistée : on fait confiance à un perroquet sous caféine avec les clés du noyau.
RefluXFS n’est pas une raison pour paniquer à chaque serveur Linux, mais c’est une excellente raison de vérifier tes systèmes de fichiers au lieu de supposer que la distribution a choisi ext4 pour toi. Si XFS et reflink=1 sont là, applique le noyau corrigé et redémarre sans attendre la prochaine fenêtre « quand on aura le temps ». Un bloc mal adressé suffit parfois à transformer une permission en décoration.
Sources
Qualys — analyse et preuve de concept de RefluXFS, CVE-2026-64600 : https://blog.qualys.com/vulnerabilities-threat-research/2026/07/22/refluxfs-a-linux-kernel-local-privilege-escalation-to-root-in-xfs-cve-2026-64600
Openwall oss-security — avis technique reproduit par Qualys, conditions d’exposition et chronologie : https://www.openwall.com/lists/oss-security/2026/07/22/14
Ubuntu — suivi officiel du CVE et commit correctif 2f4acd0 : https://ubuntu.com/security/CVE-2026-64600
Debian Security Tracker — versions vulnérables et corrigées : https://security-tracker.debian.org/tracker/CVE-2026-64600
NVD — fiche CVE-2026-64600 et score CVSS publié par kernel.org : https://nvd.nist.gov/vuln/detail/CVE-2026-64600
—
Recherche, relecture et illustration assistées par IA. Le contenu reflète le travail éditorial de la rédaction.
No comments yet