On July 22, Qualys published a Linux kernel advisory that anyone running shared hosting on a RHEL-family system should read before doing anything else: CVE-2026-64600, nicknamed RefluXFS. It is a local privilege escalation to root in the Linux kernel’s XFS filesystem, and the proof-of-concept Qualys published strips the root password from /etc/passwd in seconds — starting from an ordinary, unprivileged local account.

The vulnerability has been sitting in the kernel since version 4.11, released in 2017. Nine years of shared hosting servers, VPS instances, and cloud nodes, quietly exposed.

What is happening

XFS supports a feature called reflink, which allows filesystem blocks to be shared between multiple files — the same mechanics that make copy-on-write filesystems efficient for things like snapshots and fast copies. When two processes perform direct I/O (O_DIRECT) writes to reflinked files at the same time, the kernel has to allocate new private blocks for each writer. During that allocation, the kernel briefly drops the inode lock while it waits for transaction log space.

In that window, a second writer can finish its own remap cycle and alter the block’s reference count. When the first writer resumes, it re-reads the count using a stale physical block address it captured before the lock drop. Seeing a count of one, it assumes the block is already private and writes directly to what is actually a shared block on disk — potentially overwriting a file it should never touch.

The attack path Qualys demonstrated: race the XFS copy-on-write allocator to overwrite /etc/passwd, remove the root password hash, call su. Done. The modification persists through reboots, and there is no kernel log output whatsoever. Your SIEM will not see it.

Who is actually affected

Three conditions must be true simultaneously: an unpatched kernel, an XFS filesystem, and reflink enabled (reflink=1 in the filesystem superblock). That combination is the default configuration on RHEL 8, 9, and 10; CentOS Stream 8, 9, and 10; Oracle Linux 8, 9, and 10; Rocky Linux; AlmaLinux; Amazon Linux 2023 — and critically for the hosting industry — CloudLinux 8, 9, and 10.

Qualys estimates more than 16.4 million systems meet all three criteria.

Debian, Ubuntu, and SUSE do not use XFS as their default root filesystem, so standard installations are not affected. An administrator who manually selected XFS during setup and enabled reflink would be in scope.

The fix

The upstream patch merged into the Linux kernel tree on July 16, 2026. All major RHEL-family distributions have backported it, and the relevant RHSA, ALSA, RLSA, and ELSA errata are listed in the Qualys advisory.

A few points worth knowing before you call this done:

Applying the package update is not enough. The new kernel has to actually run, which requires a reboot. Patching the package and skipping the reboot leaves the vulnerable kernel loaded in memory.

There is no workaround. SELinux in Enforcing mode does not block the affected XFS allocation path. Container namespaces, KASLR, SMEP, and seccomp profiles all operate at different layers and do not protect against a block-layer write. If you cannot reboot immediately, the only real mitigation is to restrict local account access on that machine until you can.

What this means for kalfaoglu.net customers

The risk profile here is unusual for a local privilege escalation. The attacker does not need your account specifically — they need any local account on the same server. On a multi-tenant shared hosting machine, that means every other customer’s account is a potential entry point.

If you are on shared hosting with a provider running CloudLinux or another RHEL-family distribution, the patch has been available since late July. Ask your provider directly whether they have applied kernel updates for CVE-2026-64600 and completed reboots. Any serious host should be able to answer that without hesitation.

If you manage your own VPS or dedicated server on a RHEL-based system — RHEL, AlmaLinux, Rocky, CentOS Stream, Oracle Linux, Amazon Linux 2023 — check your running kernel version (uname -r) against your distribution’s current errata, apply the kernel update, and reboot. SELinux will not save you here; the flaw operates below everything you rely on for containment.

The exploit is public, reliable, and leaves no trace. The patch is out. The only remaining variable is whether the right kernel is actually running.