A major vulnerability has been discovered in the XFS file system of the Linux kernel. Dubbed RefluXFS, this vulnerability allows a local user without privileges to gain root access. Distributions such as RHEL, CentOS, and AlmaLinux are particularly affected, raising a significant concern for system administrators.
RefluXFS, identified as CVE-2026-64600, relies on a nine-year-old vulnerability. This flaw exploits the reflink functionality of the XFS file system to silently overwrite critical files belonging to root. The lack of log traces makes this attack nearly undetectable.
Discovered through the combined research of Qualys and Anthropic, RefluXFS challenges many classic defense mechanisms present in Linux systems. Here’s a technical dive into this vulnerability, which deserves our full attention.
How RefluXFS leverages the XFS file system to escalate root privileges
RefluXFS leverages the reflink feature introduced in XFS, which allows cloning files without copying the data. A standard user can thus duplicate a protected file, such as /etc/passwd, simply by using read access. This creates a copy that shares the same physical disk blocks as the original file.
The problem arises during a direct write (O_DIRECT) to this clone. The kernel briefly releases a lock, then performs an outdated check on the block sharing. A concurrent write can then rewrite the data on the original blocks without the inode or permissions being modified.
This situation is comparable to a craftsman who repaints a wall he was told not to touch, secretly and without leaving any visible traces. The result: an illegally modified root file can execute code with full privileges, granting stealthy root access.
The insidious danger: persistent, untraceable root access
What makes RefluXFS particularly formidable is that the modification is written at the block level to the disk. This means that the metadata remains intact. The modified binary retains its SUID bit, allowing for privilege escalation during its execution.
Furthermore, this alteration persists after a reboot, making the intrusion persistent. No kernel log records this activity, thus circumventing standard detection tools. It’s a bit like favoring a thief who winds his watch after breaking a window.
Known protection mechanisms like SELinux, KASLR, SMEP, or SMAP fail to detect anything because the vulnerability manipulates the deep layer of block allocation in the filesystem. A failure in this mechanism renders traditional security defenses ineffective.
Affected machines and conditions for exploiting the RefluXFS vulnerability on RHEL, CentOS and AlmaLinux
The vulnerability affects all Linux kernels since version 4.11, which is almost all versions maintained today. The filesystem must be XFS and use reflink enabled (reflink=1). Finally, an unprivileged user must have write access to a directory located on the same partition as the critical root files.
These conditions are met in many default installations. For example, the /var/tmp directory is often writable by all users and is located on the same partition as /etc and /usr/bin. This creates fertile ground for exploiting the vulnerability.
The affected distributions include RHEL 8, 9, and 10, CentOS Stream, AlmaLinux, Rocky Linux, Oracle Linux, and Amazon Linux. Together, these systems comprise approximately 16.4 million vulnerable machines, according to Qualys. Debian, Ubuntu, and Fedora Workstation are not affected in their standard configuration, as they do not use XFS for the root directory.
SELinux and other protections: why they are not enough against RefluXFS
It’s tempting to take refuge behind SELinux in enforcing mode, thinking you’re safe. Unfortunately, this belief is mistaken with RefluXFS. SELinux protections, even in strict mode, cannot block this vulnerability.
Kernel locking, isolated containers, and even KASLR, SMEP, or SMAP do not detect or prevent exploitation. The vulnerability operates by bypassing standard filesystem-level permission management, rendering these defenses ineffective.
A Red Hat engineer proposed a temporary solution: a SystemTap script that disables the xfs_file_remap_range function, the source of the problem. This is an emergency workaround, but it breaks the reflink functionality for applications that rely on it.
The official patch and best practices for protecting against RefluXFS in 2026
The good news is that a patch integrated into the Linux kernel has been available since July 16, 2026. This patch fixes the race condition at the heart of reflink in XFS and neutralizes the attack. RHEL-based distributions have already released targeted updates.
For RHEL and its derivatives, the corrected versions are 4.18.0-553.144.1.el8_10 for branch 8.10, 5.14.0-687.26.1.el9_8 for 9.8 and 6.12.0-211.34.1.el10_2 for 10.2. These updates should be applied without delay.
In the meantime, disabling Reflink with a script or modifying your system configuration are emergency measures. The stakes are clear: prevention is better than cure, especially when faced with such a treacherous vulnerability that bypasses traditional protections.