# Nine Years in the Kernel: The XFS Race Condition That Hands Root to Any Local User on RHEL
Anyone with an unprivileged shell on a default Red Hat Enterprise Linux install can now escalate to root. That sentence deserves a moment to sit.
CVE-2026-64600 — dubbed RefluXFS by its discoverers at Qualys — was disclosed yesterday after sitting undetected in the Linux kernel for nine years. It lives in the XFS filesystem driver, it's a race condition, it overwrites root-owned files, and Qualys says they proved it works on stock RHEL installs, Fedora Server, and Amazon Linux. If your enterprise runs the most common Linux distribution in North American datacenters on its default filesystem, you're in the affected population. That's most of them.
## The Bug Itself: Race to the Root
RefluXFS is a local privilege escalation. Remote exploitation isn't in the picture — an attacker needs a shell first. But "local only" has become an increasingly thin comfort in the era of cloud VMs, shared hosting, container breakouts, and phishing campaigns that land initial access.
The mechanics are a race condition in XFS's write path. Race conditions in kernel code operate on timing windows — two threads accessing shared state where the order of operations isn't guaranteed. In this case, Qualys found a window during certain file operations on an XFS filesystem where an unprivileged process can slip past the permission checks that are supposed to stop it from touching root-owned files. Win the race, and you can write to files owned by root. Write to the right files — /etc/passwd, /etc/sudoers, a setuid binary — and root is yours, persistently.
The word "persistent" is doing heavy lifting there. This isn't momentary. Once you've written to the right target, the privilege escalation survives reboots. You're not exploiting a transient condition; you're modifying the system's permanent state. That's rootkit-tier impact from a user-space starting point.
Race conditions are notoriously hard to reproduce consistently, which is sometimes cited as a mitigating factor. Qualys demonstrated this one works. Demonstrated, in this context, means they built a working proof of concept and ran it. How reliable is their exploit? They haven't published full technical details yet, which is standard responsible disclosure practice, but the fact that they demonstrated it should remove any optimism about this being theoretical.
## Why XFS, Why RHEL, Why Now
Red Hat made XFS the default filesystem for RHEL 7 in 2014. Every default RHEL install since then — including RHEL 8, RHEL 9, and the full downstream ecosystem of CentOS Stream, AlmaLinux, Rocky Linux — ships with XFS as the root filesystem unless an administrator actively chose otherwise during installation. Most didn't. That's not a knock on administrators; default-sane choices are part of what makes RHEL trustworthy for enterprise deployments. But it means the affected surface area is enormous.
Amazon Linux is in the list too. AWS runs a significant portion of the internet's backend on fleets of Linux instances. Amazon Linux's inclusion means cloud-hosted workloads across every industry are in scope. A developer instance with a compromised user account. A CI/CD runner where someone's build pipeline got poisoned. An analytics worker where an attacker landed via a misconfigured service. All of these become root compromises if the instance is running XFS and the attacker has any code execution.
Fedora Server rounds out Qualys's disclosure, which matters less for enterprise but keeps the vulnerability relevant for infrastructure teams running Fedora in internal environments.
## Qualys and the Pattern You Should Know
This isn't the first time Qualys has handed the Linux security community a nine-alarm fire. Their research team has developed a specialty in finding old, serious privilege escalation bugs in Linux that everyone else missed:
The Qualys pattern is worth internalizing: they find bugs that are old, that live in components everyone uses, and that work on default configurations. They don't find edge cases. They find the mainline.
RefluXFS fits the profile exactly. XFS has been in the mainline kernel since 2002. RHEL has been the dominant enterprise Linux since the early 2000s. A race condition in a filesystem driver is exactly the kind of quiet, non-obvious bug that can survive a decade of security reviews because it requires a specific timing condition, not an obvious input validation failure.
## What Defenders Need to Do Right Now
The patch is the obvious answer. Red Hat's security team will issue a kernel update; RHEL subscribers should treat this as P1. Amazon Linux will push an update through its update mechanism. Apply it.
For environments where patching can't happen immediately:
Identify your exposure first. Any system running XFS as its root filesystem or for any mounted volume with untrusted user access is in scope. Run df -T across your fleet. If XFS appears and users you don't fully trust have shell access, treat that host as compromised-until-patched.
Restrict local user access. This is a local exploit — no local access, no exploitation. Multi-tenant environments (anything with SSH keys for multiple engineers, contractor accounts, developer VMs) are your highest risk. Consider temporary access restrictions on privileged directories for accounts that don't need them.
Audit recent filesystem activity. Qualys demonstrated this works, which means a working exploit will exist in the wild soon, if it doesn't already. Check /etc/passwd modification times. Check /etc/sudoers. Check setuid binaries with find / -perm -4000 -type f and compare against known-good baselines. If something changed in the last 24 hours and you didn't change it, that's worth investigating.
Watch for race condition exploitation signatures. This won't show cleanly in application logs, but filesystem audit logs via auditd and integrity monitoring tools like AIDE or Tripwire should catch post-exploitation file modifications. If you weren't running integrity monitoring before, today is the day to start.
---
## HackWire Analysis
The nine-year lifespan of RefluXFS is the detail that demands attention, but not for the obvious reason. Nine years sounds like a failure. It isn't — or at least, it isn't only that. It's a structural reality of how security research interacts with a kernel that ships 10-15 million lines of code maintained by thousands of contributors.
What the lifespan tells us is that filesystem code — specifically, the race condition patterns in complex write paths — is systematically under-audited relative to its attack surface. Dirty Cow (CVE-2016-5195) was a decade-old race condition in the kernel's copy-on-write mechanism. DirtyPipe (CVE-2022-0847) was a newer variant attacking the pipe mechanism. Now RefluXFS attacks XFS's write path. The pattern across these bugs isn't sloppy kernel developers — it's that race conditions are genuinely hard to identify through code review. They require dynamic analysis, concurrency testing, and adversarial fuzzing of timing windows, not just reading the code.
The deeper concern for enterprises isn't this specific CVE — it's the reasonable inference that there are more like it. If Qualys keeps pulling on the thread of Linux filesystem race conditions and keeps finding root-level bugs, the question defenders should be asking isn't "are we patched for this one?" It's "what's our posture for the next one, which will probably land before we've finished deploying this patch across a heterogeneous fleet?"
The answer to that question isn't a tool — it's a practice. Consistent runtime integrity monitoring, tight user access controls, and aggressive patching cadence for kernel updates aren't defensive measures for known bugs; they're the baseline that limits the blast radius of the unknown ones.
RHEL shops that are still negotiating maintenance windows for this patch in two weeks should treat that negotiation as the actual finding. The vulnerability is the forcing function, not the problem.
— HackWire Editorial
---
## Related Coverage