RefluXFS: a Linux XFS flaw gives any local user root access

A local root exploit is bad. A local root exploit that writes no kernel log, survives a reboot, and never touches the file it rewrote is a detection problem. That is the real weight of RefluXFS, the XFS filesystem flaw Qualys disclosed on July 22 and tracks as CVE-2026-64600. Any unprivileged user on a vulnerable host can overwrite a root-owned file, and the machine keeps insisting nothing happened.

The bug is a race condition in the Linux kernel's XFS copy-on-write path that has sat there since kernel 4.11 shipped in 2017. On an XFS volume created with reflink support, an attacker makes a reflink copy of a target such as /etc/passwd or a setuid-root binary into a throwaway file under their own control, then fires overlapping direct writes at that copy. A brief window where the kernel drops and reacquires a lock lets one of those writes land in the physical block still backing the original file, according to reporting from BleepingComputer. Qualys said the race is highly reliable and usually wins within about ten seconds. The result is root.

Who is exposed, and who is not

The headline that ran everywhere was "nine-year-old Linux flaw gives root." That framing is too broad, and for a defender triaging a fleet it is the wrong question. The exposure is not "Linux." It is "XFS as the root filesystem with reflink turned on," and that maps almost exactly onto the Red Hat family and the enterprise hosting stack built on it.

Red Hat Enterprise Linux 8, 9 and 10 create XFS with reflink by default, and so do Rocky, AlmaLinux, Oracle Linux, CentOS Stream and CloudLinux, plus Fedora Server 31 and later and Amazon Linux 2 and 2023, per The Hacker News. Debian, Ubuntu and SUSE do not use XFS for the root filesystem by default, so a stock install of those is not vulnerable unless someone chose XFS deliberately. RHEL 7 predates reflink and is out of scope. Qualys put the exposed population at more than 16.4 million systems by its own asset-management telemetry.

The practical read: if you run RHEL-derived servers, shared hosting on CloudLinux, or Amazon Linux, treat this as your work for the week. If your fleet is Debian or Ubuntu, confirm your root filesystem is not XFS and then move it down the list. You can check a host directly with xfs_info / and looking for reflink=1.

Why your existing controls will not see it

This is where RefluXFS earns attention beyond "another local privilege bug." Qualys reported that the exploit runs underneath the defenses most teams lean on. Enforcing-mode SELinux, seccomp filtering, kernel lockdown, the isolation a container is supposed to provide, and the usual memory hardening (address-space randomization, the supervisor-mode execution guards) all failed against it in testing. The write bypasses the page cache and goes straight to the block device, so it produces no kernel warning. It does not change the target file's inode metadata. And the modification is on disk, so it survives a reboot.

Put those properties together and you get the uncomfortable part: there is no clean signal for the race itself. Your audit pipeline, your SIEM, your EDR watching syscalls, none of them get a reliable event to fire on. A privilege escalation that leaves your telemetry blank is functionally invisible until the attacker does something noisy with the root they just took.

The detection you have left

If you cannot catch the technique, catch the outcome. The exploit's whole point is to change a root-owned file, so file integrity monitoring on a short, high-value list is the compensating control while you stage patches: /etc/passwd, /etc/shadow, /etc/sudoers, the sudoers drop-in directory, and your setuid-root binaries. An unexpected content change to any of those on a host that has not been rebooted onto a patched kernel is your alarm. This is the same lesson we drew from DirtyClone, which rewrote /bin/su in memory and left the on-disk file untouched: when the exploit hides the technique, you monitor the target, not the method. Watch for the second-stage tells too, a new UID 0 account, an unexpected setuid bit, an out-of-band cron or systemd unit.

The reboot window is your real exposure

The good news in the timeline is that the fix landed before the flaw went public. The upstream kernel patch merged on July 16, and Red Hat's errata began going out around July 14, roughly a week ahead of disclosure. Qualys confirmed there is no workaround: you cannot disable reflink on an XFS filesystem after it is created, and no mount option or sysctl turns the behavior off.

So the only remediation is the patched kernel, and here is the operational sting that the patch-now coverage skips. A kernel package installs in minutes, but a kernel fix does nothing until the host reboots onto it. On always-on production servers and dense multi-tenant hosts, your true remediation deadline is not your patch-download time, it is your next maintenance window. Live-patching services such as kpatch may not cleanly cover a fix that reworks a filesystem allocation path, so verify with your vendor rather than assuming a hot patch closed it. Until a host is rebooted onto the fixed kernel, it is still exploitable, and your file integrity monitoring is what stands in the gap. Operators who hand out local accounts, from shared hosting to CI runners, should assume the window is being probed. We made the same point about tenant-to-root exposure on shared cPanel hosting.

An AI found this, and that resets the clock on old bugs

One detail in the disclosure deserves more weight than it got. According to Qualys's own account, it did not find RefluXFS by hand. Its researchers used an AI model, Anthropic's Claude, to help surface and prove the flaw, with the model assisting in producing a working exploit against a default RHEL system. This is the second AI-assisted kernel finding from the same research team in a short span, alongside a snap-confine privilege bug earlier in the year.

The practitioner takeaway is not "AI is scary." It is that the dormant-bug backlog is now being mined at machine speed. A race condition that survived nine years of human review got walked out into the open because a model could explore the interleavings a person would not sit and enumerate. "Old and quiet" has stopped being a proxy for "safe." The same technique that surfaced this for Qualys is available to anyone, so the interval between a subtle kernel flaw existing and someone weaponizing it is shrinking. That raises the cost of every server you cannot reboot on demand, and it is the same pressure we flagged with GhostLock turning any Linux foothold into host root and the default sudo path in Red Hat's directory stack.

Patch, reboot, then watch your root-owned files

Concrete order of operations for a RefluXFS response:

• Inventory the exposed hosts. Flag every RHEL-family, CloudLinux, Fedora Server or Amazon Linux box, and confirm XFS-on-root with xfs_info / and a reflink=1 check.

• Install the patched kernel and schedule the reboot. The package is not the fix; the reboot onto it is. Prioritize hosts where untrusted users hold local accounts.

• Turn on file integrity monitoring in the gap. Alert on any change to /etc/passwd, /etc/shadow, /etc/sudoers and setuid-root binaries on un-rebooted hosts.

• Verify no live-patch shortcut. Do not assume kpatch closed a filesystem-path fix; confirm with your vendor before you count a host as done.

RefluXFS is not a remote catastrophe. It needs a local account, and there is no evidence yet of exploitation in the wild. But it is a clean, reliable path from any foothold to root on the exact server families that run production workloads, with no workaround and no honest way to know after the fact whether it was used. That combination is why it belongs at the top of this week's list, not the bottom.