RefluXFS (CVE-2026-64600): root on 16 million servers through XFS — and SELinux won't save you

This time it's the Red Hat family's turn

The last root escalations we covered here — DirtyClone, ssh-keysign-pwn — came in through the network stack or ptrace, and Canonical published the big advisory. This one differs in two ways that matter: it lives in the filesystem, and the impact lands squarely on the RHEL family — AlmaLinux, Rocky, Oracle Linux, CentOS Stream, Amazon Linux — which is where a good share of our clients' servers run.

On 22 July, the Qualys Threat Research Unit published RefluXFS (CVE-2026-64600). Their estimate: more than 16.4 million systems potentially affected. We're writing this today because of one particularly awkward property — you cannot mitigate it. Either you patch and reboot, or you stay exposed.

In one sentence

A local user with no special privileges can trigger a race condition in XFS that lets them overwrite protected system files — /etc/passwd or a SUID binary — and become root.

What actually breaks

XFS supports reflinked files: two files sharing the same on-disk blocks until one of them is modified. When that happens, the kernel performs copy-on-write — it allocates a new private block, writes there, and remaps the file to point at the new block. It's the mechanism that makes cp --reflink instant and free until something changes.

The flaw sits in a crack in that process. While waiting for transaction log space, the kernel briefly drops its inode lock. That pause is the window. If a second concurrent O_DIRECT write against the same reflinked file slips in at that moment, it completes its cycle first, remaps the file and drops the reference count. When the first writer resumes, it holds a stale reference and writes straight into the original block — the shared one it should never have touched.

That's the prize: if that original block belongs to a privileged file, you have just written inside it without permission to do so.

Qualys's proof of concept uses exactly that to surgically modify /etc/passwd or root SUID binaries. And the changes it makes persist across reboots, produce no kernel log output, and bypass standard file metadata checks.

What makes this one especially nasty: nowhere to hide

With most escalations of this kind there's some stopgap while you wait for a reboot window. With DirtyClone, disabling unprivileged user namespaces closed off the convenient exploitation path.

Not here. In the advisory's own words, this isn't a vulnerability you can harden around, isolate, or live-patch. What doesn't help:

• SELinux in Enforcing mode: doesn't stop it. This is the detail that stands out most in the advisory.
• seccomp: doesn't stop it.
• KASLR: doesn't apply; no randomisation needs defeating.
• Container isolation: doesn't stop it.

The reason is that the exploit does nothing unusual. It uses the filesystem exactly the way it was designed to be used: two concurrent direct writes to a reflinked file. No containment mechanism sees anything anomalous, because from its point of view there isn't any.

The only fix is to update the kernel and reboot.

Who's affected

Kernel versions: 4.11 and later — that is, since 2017 — without the patch.

Vulnerable out of the box (because they mount XFS with reflink enabled by default):

Affected only if you went looking for it: Debian, Ubuntu and SUSE are not vulnerable in their default configuration. They only are if someone manually created an XFS filesystem with reflink=1. If your estate is stock Debian/Ubuntu you can breathe out — but do check anyway, because file servers and virtualisation nodes are precisely where that gets turned on.

Who can exploit it: any local user, with no special privileges or capabilities required. In practice: shared hosting, servers with third-party SSH accounts, multi-tenant environments, CI machines running other people's jobs — anywhere someone who isn't you can execute code.

How to tell in two minutes

1. Check whether you use XFS

findmnt -t xfs

Nothing returned means no XFS filesystems mounted, and this CVE isn't your problem. On RHEL 8+ and derivatives, XFS is the default filesystem, so expect it to show up.

2. Check whether reflink is enabled

sudo xfs_info / | grep reflink

Look for reflink=1 in the output. If it says reflink=0, that filesystem isn't exploitable this way. Repeat for every XFS mount point from step one, not just /.

3. Check your kernel

uname -r
rpm -q kernel --last | head -3

The version number alone tells you little here, because each distribution backports on its own schedule. Look at the package date and cross-check it against your vendor's advisory.

What to do today

Patch status, honestly

The fix was merged into the Linux tree on 16 July and distributions are backporting it. At the time of writing, not all of them have shipped packages yet. So the first step isn't to update blindly — it's to check your distribution's security advisory for CVE-2026-64600 and see whether a kernel is available.

• Red Hat: access.redhat.com/security/cve/cve-2026-64600
• AlmaLinux: errata.almalinux.org
• Rocky Linux: errata.rockylinux.org
• Oracle Linux: linux.oracle.com/security
• Amazon Linux: alas.aws.amazon.com

Once it's available: update and reboot

sudo dnf update kernel
sudo reboot

Before rebooting, confirm which kernel will actually boot:

grubby --default-kernel

Accidentally rebooting into the old kernel at three in the morning remains the classic worth avoiding. And yes: the reboot is mandatory. There's no live patch for this one.

While you wait for the package

There's no technical mitigation, but you can reduce who is able to try, which is all that's left:

• Review who holds local accounts on affected machines and suspend any that aren't essential for a few days.
• Prioritise by exposure: machines with users you don't control come first.
• If you have an XFS filesystem with reflink enabled that doesn't need it, discuss it with your provider — but be careful, this isn't a toggle: changing reflink on an existing XFS filesystem is not trivial and isn't something to attempt casually in production.

To be clear, because it's easy to fool yourself here: none of this fixes the flaw. It only shrinks the attack surface until the patch lands.

If you suspect it already happened

Remember that this exploit leaves no kernel log trace and its changes survive a reboot. It's the opposite of DirtyClone, where rebooting erased the evidence: here the evidence stays put, but it's a modified file, not an alert.

The obvious checks are worth running:

# UID 0 accounts that shouldn't be there
awk -F: '$3 == 0 {print $1}' /etc/passwd

# Root SUID binaries, cross-checked against what the package manager recorded
find / -xdev -perm -4000 -user root -type f 2>/dev/null
rpm -Va --nomtime --nordev 2>/dev/null | grep '^..5'

That last command compares installed files against the hashes RPM recorded. Because the on-disk file genuinely does change with this flaw, rpm -Va is a properly useful tool here. If a privileged binary shows an altered hash and no update explains it, treat the machine as compromised: rotate credentials and keys before anything else.

What we're doing

The order we're following on the machines we manage is the usual one, sorted by who can execute code on them:

1. Servers with third-party local accounts: shared hosting, client SFTP, multi-tenant environments. These already have a potential attacker on the inside.
2. CI and container nodes: where code we didn't write runs.
3. Single-admin VPS: minimal local surface, last in line.

In parallel, we've inventoried which machines mount XFS with reflink so we're not checking blind. The ones that don't simply aren't part of this round.

The takeaway

RefluXFS can't be fired from the internet: it needs a local account. If you're the only person who touches your servers, the real risk is low and it can wait for your normal maintenance window.

But if there are users on your machines you don't fully control, this one is worth stepping outside the usual calendar for, and for one very specific reason: it's one of the few where the answer to "can I do anything in the meantime?" is no. Not SELinux, not containers, not configuration hardening. Only the patch.

And the underlying lesson is the same as every time one of these lands: check the kernel version, check the last reboot date, update, reboot, verify. If your patching plan today amounts to "whenever I remember", let's talk.

References

• RefluXFS: A Linux Kernel Local Privilege Escalation to Root in XFS (CVE-2026-64600) — Qualys Threat Research Unit
• RefluXFS CVE-2026-64600: XFS Root Privilege Escalation Hits 16.4M Systems — SecurityOnline
• RefluXFS Linux Kernel Vulnerability Lets Attackers Gain Root Access — Cyber Security News
• CVE-2026-64600 — Red Hat Customer Portal