RefluXFS (CVE-2026-64600)

RefluXFS (CVE-2026-64600) is a local privilege-escalation vulnerability in the Linux kernel's XFS filesystem: specifically in its copy-on-write, or reflink, path. It was disclosed on 22 July 2026 by the Qualys Threat Research Unit (TRU), in collaboration with Anthropic. In plain terms, an ordinary local user with no special permissions can abuse a timing flaw in how XFS handles shared disk blocks to overwrite protected system files and escalate all the way to root.

The vulnerable code has been present since Linux kernel 4.11, released around 2017, roughly nine years old at the point of disclosure. It affects all mainline and stable kernels since then that lack the fix, on any XFS volume with reflink enabled. That last condition sounds like a niche caveat, but it is the opposite: reflink-enabled XFS is the default filesystem configuration on the entire Red Hat family of distributions, which underpins a large share of the world's production Linux servers. Qualys estimates that over 16.4 million systems worldwide are potentially affected.

CVE-2026-64600 is local-only (it cannot be triggered directly from the internet) and at the time of disclosure there were no confirmed reports of exploitation in the wild. Three of its properties, though, make it stand out from the usual run of kernel escalation bugs, and we'll return to each: it bypasses SELinux even in Enforcing mode, it leaves no kernel log output, and the changes it makes on disk persist across reboots.

To understand RefluXFS you need one idea: copy-on-write. XFS supports reflinks, two or more files that share the same physical blocks on disk to save space, until one of them is written to. When a process writes to a shared block, XFS doesn't overwrite it in place, because that would corrupt every other file pointing at it. Instead it performs copy-on-write: it allocates a new private block, remaps the file to point at that new block, and decrements the reference count on the original shared block.

That sequence has to be atomic to be safe, and here is the crack. To avoid deadlocks, the kernel briefly drops its inode lock while it waits for space in the XFS transaction log. For a few microseconds the file is unlocked mid-operation. That gap is a race window. If two O_DIRECT writes to the same reflinked file run concurrently, they can collide inside that window so that the first writer ends up using a stale physical block address: the address of the original, still-shared block rather than its own freshly allocated private copy. The write lands in the protected file's block instead of the attacker's.

A local user weaponises that by racing writes on purpose, thousands of times, until one lands in a file the operating system trusts: a binary that runs as root, a configuration file that grants privilege. Overwrite the right file and the ordinary account that started the attack is now root. No memory corruption exploit, no shellcode: just a filesystem doing exactly what it was told, at the wrong moment, with the wrong block address.

RefluXFS is local-only. An attacker must already be able to run code on the server as some local user before they can trigger the race. They cannot fire it at your store from the internet. It is tempting to read "local" as "not my problem." For an ecommerce server, that reading is wrong, and it's wrong for the same reason it was with GhostLock (CVE-2026-43499) and CVE-2026-23111.

Magento 2 is one of the most actively attacked ecommerce platforms in the world, and successful attacks follow a well-worn chain: exploit a vulnerable extension, an unpatched core CVE, or a weak admin credential; drop a webshell running as the web-server user (www-data or nginx); then work outward. That webshell is precisely the "unprivileged local user" RefluXFS requires. A low-privilege foothold that yesterday could only rummage through files the web user owns can, with RefluXFS, become root on the entire server.

From root, an attacker can:

• →Read every customer record, order, and stored payment token on the server
• →Inject Magecart-style card skimmers directly into your checkout code
• →Install persistent rootkits, and because RefluXFS writes to disk, they survive reboots
• →Disable monitoring and tamper with audit logs to hide the compromise
• →On shared or multi-tenant hosting, reach every other store on the same server

"Local" doesn't mean low impact. It means "the second step of a two-step attack", and Magento supplies the first step often enough that an unpatched local escalation on a card-handling server is a real, present threat. We keep a running guide to the web-layer half of that chain in our Magento Security Centre.

The single most important fact about RefluXFS for a Magento store owner is not the mechanism: it's the default. Reflink-enabled XFS is the standard, out-of-the-box filesystem configuration on the Red Hat family:

Read that list against how UK Magento hosting is actually built. The overwhelming majority of shared and semi-managed Magento hosting runs on cPanel with CloudLinux, which sits on top of the RHEL family: AlmaLinux and CloudLinux kernels descend directly from it. Reflink-enabled XFS is the filesystem they ship on by default. In other words, the exact configuration RefluXFS targets is the exact configuration most shared UK Magento hosts run. If your store is on cPanel shared hosting, the safe assumption is that the box is in scope until your provider tells you otherwise.

Plenty of hosts reassure customers with a single line: "we run SELinux in Enforcing mode." For a lot of threats that is a genuine mitigation. For RefluXFS it isn't, and that's what makes this bug especially nasty on a shared host.

• It bypasses SELinux in Enforcing mode. The exploit operates at the filesystem block layer, beneath the point where SELinux policy is applied. By the time the stale-address write happens, the security decision has already been made against the wrong file. The "we run SELinux" reassurance simply does not reach this bug.
• It leaves no kernel log output. A successful exploit doesn't trip an oops, a warning, or a stack trace in dmesg. To anything watching kernel logs, nothing happened. That silence makes detection far harder than for a bug that crashes or complains on the way through.
• The changes persist across reboots. Because RefluXFS overwrites files on disk rather than manipulating live kernel memory, whatever an attacker plants (a modified binary, a backdoor account, a rootkit loader) is still there after a restart. You cannot reboot the problem away.
• Container boundaries don't stop it either. Qualys reports that alongside SELinux, the exploit also defeated seccomp, kernel lockdown and container boundaries in testing. That last one matters most for shared hosting: the container-style tenant isolation many cPanel and CloudLinux platforms rely on to separate customers does not contain a RefluXFS escalation, because the bug lives in the shared kernel those containers all sit on. Only genuinely separate hardware removes the shared kernel from the equation.

Put those three together and RefluXFS is close to an incident-responder's worst case on a shared host: a root escalation that the standard reassurance doesn't cover, that writes nothing to the logs you'd check first, and that outlives the reboot you'd reach for. On a multi-tenant box where one compromised neighbour is enough, that combination is exactly why architecture, not just patch status, decides your real exposure.

SSH into your server and run:

uname -r

Compare the kernel version against your distribution's security advisory for CVE-2026-64600. The upstream fix was merged around 16 July 2026, and vendors have begun shipping backported, patched kernels:

• AlmaLinux: check the AlmaLinux security advisories (ALSA) for CVE-2026-64600, common under cPanel-based Magento hosting
• Rocky Linux: check Rocky's errata for the patched kernel covering CVE-2026-64600
• Oracle Linux: see the Oracle Linux security advisory (ELSA) for CVE-2026-64600
• RHEL: check the Red Hat CVE page and RHSA erratum for CVE-2026-64600
• Amazon Linux: check the Amazon Linux Security Center advisory (ALAS) for CVE-2026-64600 on both AL2023 and AL2

If your kernel is older than the fixed version listed by your distribution, you are vulnerable. The fix is to update via your package manager (dnf, yum on the RHEL family) and reboot the server: a kernel update only takes effect once the machine restarts on the new kernel.

Kernel patches are applied on EveryHost servers as part of standard managed UK Magento hosting. Customers don't opt in, pay extra, or file a ticket. As distribution kernels carrying the CVE-2026-64600 fix land, they are being applied across the fleet, with the reboot each patched kernel needs scheduled per server.

We are not claiming our Sentinel WAF blocks RefluXFS. It doesn't. RefluXFS is a filesystem-layer kernel bug, not a web-layer one, and no WAF can mitigate it. What Sentinel does is block the web-layer foothold chain: the Magento exploits, webshell uploads, and brute-force attacks against admin endpoints that an attacker needs before RefluXFS is even reachable. A privilege-escalation bug with no low-privilege foothold to escalate from is a patch item, not an incident.

And we are not claiming immunity, because there isn't any. RefluXFS sat in the XFS code for nine years; something else is sitting there now. Honest security posture is patch cadence, plus defence in depth at the web layer, plus an architecture that contains the blast radius when, not if, the next kernel bug is disclosed.

RefluXFS draws the same sharp line between shared and single-tenant hosting that every kernel root bug does, but the SELinux bypass and log silence make it draw that line harder. On shared or multi-tenant infrastructure, one tenant's web-layer foothold plus RefluXFS equals root on the whole node, and every store, database and stored credential on it. The security of your store becomes the security of the least-patched, worst-maintained neighbour you happen to share a server with, and because the intrusion leaves no kernel logs, you may not even know it happened.

On single-tenant dedicated hosting there is no Store B or C. The blast radius stops at one server.

EveryHost runs single-tenant dedicated Magento servers. Your server runs your kernel, used by nobody else. A RefluXFS-class bug on EveryHost still requires patching (we patch, and we reboot onto the fixed kernel), but the blast radius of any kernel-level event is bounded to one customer's site, one customer's data, one customer's reboot window. A neighbour's foothold cannot exist, because there is no neighbour. To be completely clear: this bounds exposure, it does not grant immunity. The patch is still required, and we apply it.

That's not an argument for relaxing about kernel CVEs. It's an argument that the architecture your provider chose years before this disclosure (single-tenant or shared, dedicated or multi-tenant) quietly decided most of your exposure before the Qualys team ever hit publish.