On July 22, 2026, the Qualys Threat Research Unit disclosed RefluXFS, tracked as CVE-2026-64600, a race condition in the XFS filesystem's copy on write path in the Linux kernel. Any ordinary local user account on an affected system can trigger the bug and end up with full root privileges, and the flaw works even against machines running SELinux in Enforcing mode.
It has quietly existed since kernel version 4.11, which shipped back in 2017, and Qualys estimates it touches more than 16.4 million internet facing systems. A fix already merged upstream on July 16, and vendors are shipping patched kernels now, so the practical move for any team running RHEL, Rocky, Alma, Oracle Linux, CentOS Stream, or Amazon Linux is to patch and reboot without delay.
| Field | Detail |
|---|---|
| Name | RefluXFS |
| CVE ID | CVE-2026-64600 |
| Disclosed | July 22, 2026, by Qualys TRU |
| Type | Local privilege escalation, race condition |
| Affected component | XFS filesystem, copy on write (reflink) path |
| Kernel versions | 4.11 (2017) and later, unpatched |
| Patch status | Merged upstream July 16, 2026, vendor kernels shipping |
| Estimated exposure | Over 16.4 million systems, per Qualys |
| Bypasses | SELinux Enforcing mode, per Qualys testing |
What Happened
RefluXFS is a kernel level flaw that lets a low privilege local account overwrite protected files at the disk block layer, gain root, and leave almost no trace behind. It matters because it hits the default filesystem on some of the most widely deployed enterprise Linux distributions in the world.
I have read a lot of kernel advisories over the years, and most of them fall into a familiar rhythm. A researcher finds a memory corruption bug, a vendor scrambles, a patch ships, everyone moves on. RefluXFS does not fit that rhythm. It is not a memory bug at all. It lives in the plumbing that decides which physical block on disk a file actually points to, and that plumbing sits underneath almost every access control layer that modern Linux hardening relies on.
What makes this disclosure notable beyond the technical details is how it was found. Qualys said the discovery came out of a structured research program with Anthropic, where the Claude Mythos Preview model was used inside a manual audit workflow to help surface the concurrency flaw, with Qualys engineers independently verifying and building the proof of concept before any disclosure happened.
That mix of AI assisted triage and human validated confirmation is becoming a pattern worth watching in 2026, and it is a theme our own AI driven red teaming work tracks closely.
What is a Copy on Write Race Condition
Copy on write, or reflink, is a feature that lets XFS create what looks like a duplicate file instantly by pointing two files at the same physical disk blocks, only splitting the data apart once one of the files actually changes. A race condition happens when the kernel briefly loses track of which write should win that split, and an attacker exploits that brief gap.
Think about two roommates who share one mailbox key. Normally there is a simple rule for who gets to update the label on the box. But for one short moment, while the landlord is busy filing paperwork, the rule is not enforced. If a second roommate slips in during that gap and changes the label, the first roommate walks away thinking they updated their own mail, when really they just handed control of the box to someone else.
That is roughly the shape of what happens inside XFS during this flaw. Two write operations land on a shared, reflinked file at almost the same instant, the kernel drops its usual lock while it waits on log space, and the second operation quietly remaps the underlying block before the first one finishes. The first operation then writes to a block it no longer fully controls, and because the write method involved skips the normal page cache checks, the corrupted data lands permanently on disk.
How RefluXFS Actually Plays Out on a Real System
Qualys demonstrated the flaw on a default RHEL 10.2 install, where an unprivileged local process triggered the race, overwrote a protected system file at the block level, and ended up with passwordless root access that survived a reboot with no entries left in the kernel logs.
Three conditions have to line up for a system to be exploitable. First, the kernel has to be version 4.11 or newer without the security fix applied. Second, the XFS filesystem has to be mounted with reflink support turned on, which is the default on most modern enterprise Linux installs.
Third, the local user needs ordinary write access to some directory on that filesystem, sitting alongside a high value target such as a setuid root binary or a credential file. Put those three together and the flaw becomes something an attacker with basic shell access can turn into full root control, without needing a single credential, a phishing email, or a network exploit.
_compressed-20260723172149.webp)
What stands out to defenders is what does not happen. There is no kernel panic, no warning in dmesg, no denied entry in an audit log. The file that gets overwritten keeps its original ownership, its original permissions, and its original timestamps, so a modified setuid root binary just quietly runs as root going forward. That combination of silence and persistence is exactly why incident response teams are being told to treat this one as a priority hunting target, not just a patching task.
Who is Actually Exposed
Any distribution that defaults to XFS with reflink enabled on its root filesystem is high risk, which covers most current enterprise Red Hat family builds and Amazon Linux, while Debian, Ubuntu, and SUSE are lower risk since they default to ext4 or btrfs.
| Distribution | Default exposure | Recommended action |
|---|---|---|
| RHEL 8 / 9 / 10 | High, XFS with reflink is default | Patch immediately |
| CentOS Stream 8 / 9 / 10 | High | Patch immediately |
| Rocky Linux, AlmaLinux 8 / 9 / 10 | High | Patch immediately |
| Oracle Linux 8 / 9 / 10 | High | Patch immediately |
| Amazon Linux 2023 and AL2 (post 2022 builds) | High | Apply vendor kernel update |
| Fedora Server 31 and newer | High | Update to patched build |
| Debian, Ubuntu, SUSE | Lower, only if XFS with reflink chosen manually | Check mount config, patch if applicable |
Shared hosting providers and container platforms deserve a second look here too. On a Kubernetes node or a Docker host where every container shares the same underlying XFS root partition, this bug does not care about namespace boundaries or dropped capabilities.
A compromised container with local write access can, in principle, reach across to the host kernel through the same block layer flaw, which turns a single tenant compromise into a shared infrastructure problem. Anyone running multi tenant infrastructure should treat this as an attack surface management priority, not just a routine patch cycle item.
Why Your Existing Defenses Do Not Catch This
RefluXFS operates below the layer where SELinux, memory protections, and kernel lockdown normally do their job, which is exactly why a fully hardened, fully patched system running everything by the book can still be vulnerable if the kernel itself is not updated.
- SELinux and AppArmor evaluate access permissions before a filesystem transaction begins, and this flaw exploits what happens during the transaction itself, so mandatory access control never gets a chance to intervene.
- Memory protections like KASLR, SMEP, and SMAP exist to stop code execution style attacks, and this bug never needs to execute injected code at all, since it corrupts data directly on disk.
- Kernel lockdown mode restricts things like loading unsigned modules and direct memory access, but it places no limits on standard file operations like reflink writes.
- Container isolation through user namespaces and dropped capabilities does not extend down to raw block level filesystem operations on a shared host kernel.
How to Detect and Monitor for RefluXFS Activity
Standard logging will not show this attack, so detection has to shift toward behavioral monitoring, watching for unusual concurrent write patterns on reflinked files and verifying file integrity on high value targets rather than relying on log alerts.
Security teams that already run extended detection and response tooling should push for custom detection logic that flags rapid, concurrent write operations targeting the same reflinked extent range, since that pattern does not show up in any of the places defenders usually look.
File integrity monitoring aimed specifically at protected targets like credential files and setuid binaries adds a second layer of visibility, catching the outcome even if the technique itself slips past. This is also a good moment to revisit vulnerability management processes so that kernel level local privilege escalation bugs get the same urgency as remote code execution flaws, since the two can chain together just as easily.
Fixing It: Patching and Live Patching Options
There is no interim workaround that neutralizes this flaw short of a kernel update, since disabling reflink on an already formatted volume is not something that can be done live, so patching and rebooting is the only real fix.
| Approach | What it involves | Downtime |
|---|---|---|
| Standard kernel update | Apply vendor package update through the normal package manager, then reboot | Requires a reboot |
| Enterprise live patching | Tools such as Red Hat Kpatch, Oracle Ksplice, or Canonical Livepatch apply the fix to a running kernel | No reboot needed for the patch itself |
| Post patch verification | Confirm the new kernel is active and check filesystem stability | Minimal, verification only |
After patching, confirm the running kernel version to make sure the update actually took effect, and run a filesystem check in read only or dry run mode to verify integrity on any volume that may have been exposed before the fix was applied. Teams that lack the internal bandwidth to chase this kind of rolling patch cycle across a large fleet are exactly the audience for virtual CISO support, since prioritizing which systems get patched first, and in what order, is its own small project when you are dealing with thousands of nodes.
Hoplon Insight Box
Patch first, then verify, then hunt. Update every XFS backed host to a kernel that carries the July 16 fix, prioritizing internet facing and multi tenant systems. Confirm the update took hold with a simple kernel version check.
Then run a targeted integrity sweep on credential files and setuid binaries across systems that were exposed before the patch landed, since a silent compromise that happened before you patched will not disappear just because the kernel is now fixed.
RefluXFS in Context: A Pattern, Not an Isolated Bug
RefluXFS is the fourth major Linux kernel bug in 2026 built around tricking the kernel into writing attacker controlled data into protected memory or disk blocks, following Copy Fail, Dirty Frag, and DirtyClone earlier in the year.
| Name | CVE | Disclosed | Affected area | Core technique |
|---|---|---|---|---|
| Copy Fail | CVE-2026-31431 | April 29, 2026 | AF_ALG crypto API | Logic flaw lets a socket write controlled bytes into the page cache |
| Dirty Frag | CVE-2026-43284, CVE-2026-43500 | May 7, 2026 | IPsec ESP and RxRPC networking | Chained page cache write bugs extending earlier techniques |
| DirtyClone | CVE-2026-43503 | June 25, 2026 | Packet cloning | Dropped safety flag lets cloned packets overwrite file backed cache |
| RefluXFS | CVE-2026-64600 | July 22, 2026 | XFS copy on write path | Race condition during a lock release corrupts on disk blocks directly |
Four disclosures inside three months, all circling the same underlying idea, is not a coincidence. It suggests researchers, human and AI assisted alike, have found a rich vein in how the kernel handles concurrent writes to shared or cached data, and it would not be surprising to see more variations surface before the year is out.
Organizations that have not run a fresh cyber resilience assessment in a while may want to move that up the calendar, given how quickly this category of bug is producing new entries.
Hoplon Technical Takeaway
RefluXFS is a reminder that hardening controls only cover the layers they were built for. SELinux, kernel lockdown, and memory protections all did their job as designed here, and none of them were positioned to stop a bug living in the raw mechanics of how XFS assigns disk blocks.
The immediate task is patching every XFS backed host running kernel 4.11 or later, prioritized by exposure, followed by a targeted integrity check on credential files and privileged binaries for anything that was left unpatched over the past week.
The longer term task is making sure kernel level local privilege escalation bugs get folded into the same urgency and monitoring discipline usually reserved for remote exploits, because as this year has shown, that category is producing new entries faster than most patch cycles can keep up.
Teams weighing where to start can lean on a gap assessment to see exactly where XFS backed, reflink enabled systems sit across the environment before deciding what gets patched first.
Read More Articles:
- Linux Kernel 2026 CVE Outburst: AI Analysis & Triage
- AI Code Review Security: Torvalds Backs AI in Kernel
- Cybersecurity Weekly: 622 Patches, Zero-Days & Data Breaches
- CVE-2026-42533: Critical NGINX Vulnerability
- 7-Zip Vulnerability CVE-2026-14266: RCE Risk
- SonicWall SMA1000 Zero-Day Vulnerabilities: Patch Now
- What is AI in Cybersecurity: How It Really Protects You
- GPT-Red Explained: How OpenAI Fights Prompt Injection
-20260721112851.webp&w=3840&q=75)
