Qualys' Threat Research Unit disclosed CVE-2026-64600 on July 22, 2026 — a race condition in the Linux kernel's XFS filesystem that lets an unprivileged local user become root. Qualys named it RefluXFS. It's been sitting in the kernel since version 4.11, released back in 2017. Nine years old, and nobody caught it until now.
How a filesystem feature became a root exploit
XFS reflinks are a normal, useful feature — they let two files share the same underlying data blocks so a copy doesn't double your disk usage, the same trick behind fast VM cloning and container snapshots. The bug lives in what happens when two O_DIRECT writes hit the same reflinked file at almost the same instant. XFS's copy-on-write path doesn't lock that race correctly, and a write that should land on the attacker's own file can instead land on a completely different file's disk blocks — including one owned by root.
Chain that a few times and an unprivileged user can overwrite /etc/passwd, a sudoers file, or a root-owned SUID binary, without ever needing write permission on the target. Qualys calls it a reliable primitive, not a lucky shot — the PoC video circulating online shows it landing cleanly on RHEL 10.2, unprivileged shell to passwordless root in seconds.
Kernel 4.11 or later, unpatched — which is most Linux systems shipped in the last nine years.
The XFS filesystem mounted with reflink=1 in its superblock — the default on several major distros.
A writable location for the attacker on the same filesystem as a higher-privilege target file.
Debian, Ubuntu, SUSE — only vulnerable if XFS+reflink was chosen at install
Amazon Linux 2023, Fedora 31+
Systems on ext4 or btrfs instead of XFS
Why this is worse than a typical local privilege escalation
Most LPE bugs at least leave something behind — a crash log, a suspicious process, a kernel panic in dmesg. RefluXFS doesn't. The change hits the disk directly at the block-allocation layer, survives a reboot, produces no kernel log entry, and leaves the target inode itself untouched — a hijacked SUID binary keeps its original SUID bit and its original-looking metadata. Qualys also tested it against SELinux in enforcing mode and found the policy doesn't block the write path at all.
XFS is the default filesystem on RHEL and its downstream clones, which is exactly why RefluXFS' blast radius is so wide. · Unsplash
Timeline
2017
Linux kernel 4.11 ships the reflink copy-on-write path that contains the unpatched race condition.
July 22, 2026
Qualys publicly discloses CVE-2026-64600 as RefluXFS, with technical writeup and a PoC video on RHEL 10.2.
Late July 2026
RHSA, ELSA, and ALSA kernel advisories go out from Red Hat, Oracle, and Amazon; downstream Rocky and AlmaLinux follow.
Ongoing
A working exploit is public on GitHub — unpatched systems should be treated as exposed right now.
The fix
Check exposure: run `xfs_info <mountpoint>` and look for `reflink=1`. If it's not set, you're not vulnerable to this specific bug.
Apply your distro's kernel security update — RHSA/ELSA/ALSA advisories are already out for the major enterprise distros.
Reboot. The patched kernel does nothing until it's actually running — an unrebooted system is still exposed even after the update installs.
4
Prioritize multi-tenant boxes first: shared hosting, CI/CD runners, and any system where untrusted users get a shell.
RefluXFS, quickly
Does someone need remote access to exploit this?
No — this is local privilege escalation only. But on a shared server, CI runner, or any box where multiple people get an unprivileged shell, that's exactly the access most attackers already have after an initial foothold.
Am I safe if I'm not running RHEL or a clone?
Debian, Ubuntu, and SUSE aren't vulnerable by default because they don't default to XFS with reflink. If you specifically opted into XFS+reflink on any distro, check anyway.
Can I mitigate this without a reboot?
Not reliably. Disabling reflink on an already-provisioned filesystem isn't a clean live fix — the patched kernel plus a reboot is the real remediation.
Is this actively being exploited in the wild?
Qualys hasn't reported in-the-wild attacks as of disclosure, but a working PoC is already public, which is usually the last calm moment before opportunistic scanning starts.
This is the third kernel-or-platform-level bug in as many weeks that traces back to a race condition or a hardcoded assumption nobody revisited in years — Gitea's diff/patch git-hook RCE and JetBrains TeamCity's unauthenticated RCE both landed the same way this summer: old code, new attacker attention. If you run RHEL-family Linux anywhere with shared or semi-trusted local access — a build farm, a university lab, a hosting box — this is a today problem, not a this-sprint problem. Patch, then reboot, then actually verify the new kernel is the one running.
