RefluXFS (CVE-2026-64600): local root on Linux

On 22 July 2026 the Qualys Threat Research Unit published its analysis of CVE-2026-64600, codenamed RefluXFS — a flaw in the Linux kernel’s XFS filesystem that lets an unprivileged local user gain root. We stick here to what Qualys and the distribution vendors have confirmed, without inventing campaigns nobody has disclosed.

What the bug is

RefluXFS is a race condition in the XFS copy-on-write path, specifically on files with reflink enabled. When two concurrent O_DIRECT writes target the same reflinked file, the kernel briefly drops the inode lock while waiting for transaction-log space. In that window a second writer alters the reference state of the block. When the first process resumes, it trusts stale metadata and writes directly to the original block instead of a private copy.

The practical impact is serious: the public Qualys proof-of-concept reliably obtains root by surgically modifying /etc/passwd or a SUID-root binary. The changes persist across reboots and — importantly for defenders — leave no kernel log output.

Who is affected

The bug has existed since kernel 4.11 (2017), introduced with commit 3c68d44a2b49. Exploitation requires, at the same time: an XFS filesystem with reflink=1 (the default on most enterprise distributions), the ability to run code locally, a directory the attacker can write to, and a high-value target — a root-owned configuration file or a SUID binary.

Qualys lists as affected, among others: RHEL 8, 9 and 10, CentOS Stream, Oracle Linux, Rocky Linux, AlmaLinux, CloudLinux 8/9/10, Fedora Server 31+, Amazon Linux 2023, and Amazon Linux 2 (from December 2022). RHEL 7 is not affected. The firm estimates the scope at over 16.4 million systems.

At the time of writing no vendor had reported exploitation in the wild. Good news — but not a reason to wait: the PoC is public, and kernel patching is often the slowest part of the update cycle.

Why local root still matters

Because the flaw requires prior local access, it is easy to dismiss. That is a mistake. Local escalation is decisive wherever different, not necessarily trusted users run code on the same machine: shared hosting, CI/CD runners, developer environments, multi-tenant systems. In that model, taking over an ordinary account (say, through a vulnerable web app) and bolting on RefluXFS turns a small foothold into full control of the host.

One notable detail is how it was found: Qualys discovered the bug using Anthropic’s Claude Mythos Preview, asking it to surface a Dirty COW-like flaw. We explore that thread — AI models as a kernel-bug-finding tool — separately in AI models are starting to find real zero-days.

What to do

1. Inventory XFS + reflink systems. Check xfs_info / (the reflink=1 field) on the hosts in scope. That defines your real exposure.
2. Apply vendor kernel updates. Fixes are already backported to RHEL, Oracle Linux, AlmaLinux, Rocky Linux, CloudLinux and Fedora. There is no reliable temporary mitigation — the patch is the only fix.
3. Reboot the machines. The running kernel stays vulnerable until it is reloaded. Installing the package without a reboot does not close the hole — the most common mistake with kernel bugs.
4. Prioritise multi-tenant hosts. CI runners, shared hosting, developer servers and anywhere an untrusted user can execute code have the shortest window to update.
5. Make it a process, not a one-off. Inventory → deploy → reboot → verify the kernel version is the standard vulnerability-management loop.

The bottom line

RefluXFS calls for disciplined kernel patching and — crucially — a reboot, not panic. Because it leaves no log traces, exploitation is hard to prove after the fact, so it is better to close the exposure window before anyone finds it. If you run multi-tenant systems and want to test how fast you respond to this scenario, let’s talk.

Sources: Qualys — RefluXFS (CVE-2026-64600), The Hacker News, BleepingComputer.