Linux Kernel Flaw Exposes 16 Million RHEL Systems to Silent Root Takeover

If your enterprise servers run Red Hat Enterprise Linux or a close derivative — Oracle Linux, AlmaLinux, Rocky Linux, Fedora Server, Amazon Linux 2023 — there is a nine-year-old flaw in their default filesystem that lets any local user, with nothing more than a shell account, silently overwrite protected system files and gain full root access. The modification survives reboots. It leaves no kernel log output. And every standard Linux defense you have deployed — SELinux in enforcing mode, container boundaries, kernel memory protections, seccomp profiles — is structurally blind to it, because it operates at a layer those defenses were never designed to reach.

The flaw is CVE-2026-64600, nicknamed RefluXFS, disclosed on July 22, 2026, by Saeed Abbasi and the Qualys Threat Research Unit . Qualys estimates it affects more than 16.4 million systems worldwide , based on analysis with Qualys CyberSecurity Asset Management . It has been present in every mainline Linux kernel since version 4.11, released in 2017. A patch was merged into the Linux kernel tree on July 16, 2026 — six days before public disclosure — and vendor-patched kernels are now actively shipping for affected distributions. There is no workaround: the only remediation is applying the patched kernel and rebooting the system.

XFS is the default root filesystem on RHEL and its many derivatives, and it has been so since RHEL 7. One of its features — reflink, enabled by default with a reflink=1 flag in the filesystem superblock — lets multiple files the same underlying disk blocks without duplicating data. This is useful for virtual machine images, container layers, and large-scale storage: instead of copying 40 GB of data to create a new VM image, XFS lets the new file point to the same physical blocks as the original.

When a file sharing one of those blocks is written to, XFS must perform a copy-on-write: it allocates a new private block, remaps the file to point at the new block, and decrements the reference count on the original shared block. This sequence must be serialized to prevent corruption — XFS uses an inode lock to do that. But to avoid deadlocks in the transaction log subsystem, the kernel drops that inode lock while waiting for log space during the CoW cycle.

That lock drop is the vulnerability window. When two processes issue concurrent O_DIRECT writes — a mode that bypasses the kernel page cache and writes directly to disk — targeting the same reflinked file, a race is possible. A second writer can slip into the lock-drop window, complete its own CoW cycle, remap the file to a new block, and drop the original block's reference count to one. When the first writer re-acquires the lock, it re-reads the reference count using a stale physical block address it captured before the lock was released. Seeing a count of one, it incorrectly concludes the block is private and writes directly to the original file's physical block .

Because O_DIRECT bypasses the kernel page cache and lacks revalidation, that write reaches the disk. It overwrites the target file at the block layer, below the filesystem's metadata, below file ownership records, below setuid bits. The file's apparent ownership, permissions, and timestamps on disk remain unchanged — only its contents have been surgically modified. The modification persists across reboots. Standard file-integrity monitoring sees nothing because the filesystem metadata was never touched. And the change leaves no kernel log output .

In practical terms: an attacker with nothing more than a standard shell account can use this primitive to overwrite /etc/passwd , stripping root's password protection, or to modify a SUID-root binary to spawn a shell. A PoC demonstration on a default RHEL 10.2 deployment showed the root account's password protection stripped within seconds of the exploit running.

Three conditions must all be true simultaneously for a system to be exploitable: the system must run Linux kernel version 4.11 or later without the security patch; the filesystem must be XFS with reflink=1 set in its superblock; and the filesystem must contain both a high-value target file (a root-owned config file or SUID-root binary) and a directory writable by an unprivileged user.

Those three conditions are satisfied by default installations across a wide swath of enterprise Linux. Confirmed affected distributions include RHEL 8, 9, and 10; CentOS Stream 8, 9, and 10; Oracle Linux 8, 9, and 10; Rocky Linux and AlmaLinux 8, 9, and 10; CloudLinux 8, 9, and 10; Amazon Linux 2023 and Amazon Linux 2 AMIs from December 2022 onward; and Fedora Server 31 and later. Debian, Ubuntu, and SUSE do not use XFS by default, but administrators who manually selected XFS with reflink=1 at installation time are also exposed.

The most alarming characteristic of RefluXFS is how comprehensively it defeats the hardening stack that enterprise Linux administrators have come to rely on. This is not a failure of any individual defense: it is an architectural gap. The entire standard Linux hardening strategy — memory protections, access-control enforcement, system call filtering, container isolation — was built to police memory operations, capability boundaries, and system call access. RefluXFS operates at the filesystem allocation layer, below all of it.

Memory-protection features such as KASLR, SMEP, and SMAP are targeted at preventing code injection and arbitrary memory reads; they have no mechanism to inspect or block block-layer writes . Kernel lockdown mode places no restrictions on O_DIRECT or FICLONE for unprivileged users. SELinux in enforcing mode does not block the affected XFS code path — the exploit never triggers a policy decision that SELinux evaluates. Standard seccomp profiles do not help either, because they permit the write and ioctl calls the exploit requires.

Container environments add nothing. User-namespace restrictions, container capability limits, and hardened allocators all operate at layers the flaw never touches . A containerized workload that can write to a shared XFS filesystem is exposed in the same way as a process running directly on the host.

Qualys is explicit: this is not a vulnerability you can harden around, isolate, or live-patch. Immediate kernel patching and a full reboot are the only options.

The RefluXFS disclosure carries a second story that the security community is unlikely to ignore: how the bug was found in the first place.

Qualys tasked Claude Mythos Preview — Anthropic's most capable frontier AI model — with hunting for a race condition similar to Dirty COW (CVE-2016-5195, a 2016 privilege escalation that also exploited a CoW race condition in the Linux kernel, in that case in the memory management subsystem). Qualys researchers iteratively refined their prompts to narrow the model's focus toward race conditions in the kernel's memory-management and filesystem directories. After several iterations, the model identified the race condition in the XFS CoW path and generated a functional proof-of-concept local privilege escalation.

Qualys researchers then took over. They reviewed the model's reasoning, reproduced the exploit, and independently verified every technical claim before coordinating disclosure with upstream maintainers — Carlos Maiolino, Greg Kroah-Hartman, Darrick J. Wong, Linus Torvalds, David Woodhouse, and Willy Tarreau at the XFS maintainer and Linux kernel security team level. The model also produced an initial draft of the advisory, which the team validated and corrected against their own testing.

Claude Mythos Preview is not publicly available. Anthropic has deployed it only through Project Glasswing , a program that gives a small number of trusted organizations — primarily cybersecurity firms — access to the model for the specific purpose of evaluating how frontier AI can be applied responsibly to security research. Qualys joined the program in June 2026.

Saeed Abbasi, Head of Qualys's Threat Research Unit, was direct what the experiment demonstrates and what it does not: the lesson from RefluXFS is not that AI can be pointed at software to generate exploits on demand. The lesson is that AI paired with expert judgment helps defenders find serious flaws before attackers can abuse them.

That framing is worth examining in the context of the 2026 Linux security landscape. TechTimes covered Bad Epoll (CVE-2026-46242) earlier this month — a kernel race condition where Anthropic's Mythos model found one of two related bugs in the epoll code; a human researcher found the second independently, which Mythos had missed. RefluXFS presents the complementary data point: the same model class, operating in a different subsystem, found a bug that had survived nine years of human review undetected.

RefluXFS also follows the same structural template as Dirty COW, disclosed a decade earlier: a subtle timing flaw in a CoW path, hiding in plain sight across years of kernel releases, exploitable for privilege escalation to root, leaving no log trace. In 2016 it took a researcher stumbling across exploit samples in the wild to surface Dirty COW. In 2026, it took a structured AI-assisted audit.

The patch was merged into the mainline Linux kernel tree on July 16, 2026, in advance of public disclosure. Vendor-patched kernels are now available across affected distributions, with Qualys QID coverage spanning Red Hat, Oracle, AlmaLinux, Rocky Linux, Fedora, and Amazon Linux across more than a dozen advisories.

There is no workaround. Organizations cannot disable reflink across existing XFS filesystems without reformatting. No configuration change, seccomp policy, or SELinux rule addresses the flaw.

System administrators should take four concrete steps immediately:

Apply the latest kernel security update from your distribution vendor. For RHEL 8/9/10, the relevant advisories include RHSA-2026:39179, RHSA-2026:39984, RHSA-2026:40425, RHSA-2026:41062, RHSA-2026:41063, and RHSA-2026:41229. For Oracle Linux, ELSA-2026-39494 applies. For AlmaLinux and Rocky Linux, ALSA/RLSA equivalents covering the same kernel versions are available.

Reboot the system after applying the update. A kernel patch is not active until the machine restarts — this step is mandatory and cannot be skipped.

Verify the running kernel version after reboot, using uname -r , to confirm the patched version is in use rather than the prior kernel.

Prioritize systems where multiple users login access. The attack requires only a local account, which means shared-login servers, cloud VMs with multiple tenants, HPC clusters, CI/CD runners, and any system where a contractor, external service account, or compromised application holds even a standard shell account should be treated as highest urgency.

No in-the-wild exploitation has been confirmed as of the date of disclosure. Qualys has not publicly released the exploit code . Given that the vulnerability is highly reliable, leaves no forensic trace, and affects systems running the default filesystem configuration of the most widely deployed enterprise Linux platform, that window should be treated as narrow.

No. SELinux does not block the affected XFS code path in testing, per Qualys's own assessment. The exploit operates at the filesystem allocation layer via the O_DIRECT write path, which bypasses the kernel page cache. SELinux enforces policy on system calls, capabilities, and file access metadata — none of which are evaluated by the specific block-layer write primitive RefluXFS uses. This is not a gap in SELinux policy that can be fixed with a more restrictive configuration; it is a structural mismatch between what SELinux polices and where this attack operates.

Both are local privilege escalation vulnerabilities exploiting a copy-on-write race condition in the Linux kernel, and both leave no kernel log trace. The key structural difference is location: Dirty COW (CVE-2016-5195) exploited a CoW race in the kernel's memory management subsystem — specifically in mm/gup.c , which handles how user-space processes get physical memory pages — and was present from kernel 2.6.22 (2007) to 4.8.3. RefluXFS exploits a CoW race in the XFS filesystem's block allocation path, which is a completely different subsystem. The affected kernel versions also differ: RefluXFS requires kernel 4.11 or later with XFS reflink enabled, while Dirty COW affected older kernels that predate the XFS reflink feature.

CVE-2026-64600 requires local access — an attacker must already hold a shell account on the affected system. Remote exploitation is not possible directly. However, in cloud and hosted environments, this distinction matters less than it appears: any compromised web application, malicious dependency, or breached service account running on the host provides exactly the local foothold needed. In containerized environments where a container escape or a compromised containerized service gives an attacker a process on the host, that process has sufficient local access to attempt the exploit, since container isolation does not stop this attack.

XFS reflink is a storage efficiency feature — enabled by default on RHEL 8 and later — that lets multiple files the same underlying physical disk blocks without duplicating the data. This is valuable for VM images, container layers, and large file copies: instead of writing 40 GB of data, the new file just points at the existing blocks. The vulnerability arises because when a write to a shared (reflinked) block occurs, XFS must perform a copy-on-write to give the file its own private block. During that process, the kernel drops its inode lock briefly to wait for transaction log space. That lock drop creates a race window: a concurrent writer can slip in, remap the file, and change the reference count in a way that causes the first writer to overwrite the original shared block directly — a write that lands at the physical disk layer, below all file-system metadata and security policy enforcement.