Old Linux Bug 'RefluXFS' Hands Root to Anyone With a Shell on Default Red Hat Servers

Key points

• Researchers at Qualys disclosed a Linux kernel flaw on 22 July 2026, tracked as CVE-2026-64600 and named RefluXFS.
• The bug lets any logged-in user with no special privileges overwrite files owned by root, the top administrator account on a Linux machine.
• Default installs of Red Hat Enterprise Linux, its rebuilds, Fedora Server and Amazon Linux all meet the conditions to be exploited.
• The flaw sits in code that has shipped for roughly nine years, so the exposure window is long.
• Qualys demonstrated a working exploit that wins the race condition reliably enough to matter in production.

Another week, another kernel bug that turns a normal shell into a root shell. This one's called RefluXFS, disclosed on 22 July by Qualys, and it lives in the part of the Linux kernel that handles XFS, the filesystem format Red Hat has shipped by default for years.

If someone can log in to a Linux server at all, even as the lowest-privilege account, they can use this bug to overwrite files owned by root, the administrator account that controls the whole machine. Once you can write to the right files, you own the box.

The flaw is tracked as CVE-2026-64600. First reported by The Hacker News, the details show a race condition: a timing bug where two operations that were supposed to happen in a strict order can be nudged into overlapping, leaving the door open for a moment.

This is the third local-privilege-escalation bug we've reported in under two months, following GhostLock on 8 July and DirtyClone on 29 June. The cadence matters: defenders who treat local-priv-esc as a second-tier problem are going to keep losing ground.

Who is actually exposed?

Anyone running a default install of Red Hat Enterprise Linux, its rebuilds, or Amazon Linux. Those distributions format the root disk as XFS out of the box, which is the condition the exploit needs.

In practice that covers a very large slice of the Linux fleet inside enterprises and public cloud. Spin up an Amazon EC2 instance from the standard Amazon Linux image, or a RHEL AMI, and you're on XFS by default. Same for most on-prem RHEL boxes racked in the last decade.

The failure mode isn't remote code execution. An attacker still needs a foothold first: a low-privilege service account, a compromised web app running as nginx, or a legitimate user who's decided to go rogue. What RefluXFS does is turn any of those weak footholds into full root, quietly and without fuss.

How bad is a nine-year-old bug?

Bad, because it means every long-lived server, every golden image, every container base built on these distros in the last decade has carried the flaw. Qualys puts the age of the vulnerable code at roughly nine years.

Old bugs tend to persist in embedded systems and appliances that nobody patches. Forensic teams looking at historical breaches now have a new candidate to explain how an attacker moved from a web shell to root on a box where nothing else looked wrong.

Should you worry about the patch cycle?

Patch the kernel as soon as your distribution ships an update, then reboot. There's no clever mitigation that avoids the reboot, because the fix is in the kernel itself.

Until the patch lands, the honest advice is boring: tighten who can get a shell on these machines. Audit local accounts. Kill dormant SSH keys. Check any service account whose home directory sits on XFS and ask whether it really needs interactive login.

The post-mortem, on the day someone gets hit with this, will say the initial break-in was small and unremarkable, and RefluXFS did the heavy lifting. That's the pattern with local-privilege-escalation bugs. Never the front door. Always what turns a nuisance alert into a full compromise.