[{"data":1,"prerenderedAt":868},["ShallowReactive",2],{"switcher-blog-pareja":3,"art-refluxfs-cve-2026-64600-xfs-root-linux-kernel-en":6},{"en":4,"es":5},"\u002Fen\u002Fblog\u002Frefluxfs-cve-2026-64600-xfs-root-linux-kernel\u002F","\u002Fes\u002Fblog\u002Frefluxfs-cve-2026-64600-root-xfs-kernel-linux\u002F",{"id":7,"title":8,"author":9,"body":10,"date":853,"description":854,"extension":855,"image":856,"meta":857,"navigation":663,"pareja":858,"path":859,"seo":860,"stem":861,"tags":862,"__hash__":867},"blogEn\u002Fen\u002Fblog\u002Frefluxfs-cve-2026-64600-xfs-root-linux-kernel.md","RefluXFS (CVE-2026-64600): root on 16 million servers through XFS — and SELinux won't save you","Paco Cubel",{"type":11,"value":12,"toc":832},"minimark",[13,18,47,70,74,93,97,109,132,135,152,156,159,166,193,200,206,210,220,226,298,312,322,326,331,357,364,368,394,407,411,447,454,458,462,477,520,524,549,552,565,572,576,583,608,615,619,630,633,732,743,747,754,775,778,782,785,792,795,799,828],[14,15,17],"h2",{"id":16},"this-time-its-the-red-hat-familys-turn","This time it's the Red Hat family's turn",[19,20,21,22,27,28,32,33,37,38,42,43,46],"p",{},"The last root escalations we covered here — ",[23,24,26],"a",{"href":25},"\u002Fen\u002Fblog\u002Fdirtyclone-cve-2026-43503-traceless-root-linux-kernel","DirtyClone",", ",[23,29,31],{"href":30},"\u002Fen\u002Fblog\u002Fcve-2026-46333-ssh-keysign-pwn-linux-kernel","ssh-keysign-pwn"," — came in through the network stack or ",[34,35,36],"code",{},"ptrace",", and Canonical published the big advisory. This one differs in two ways that matter: it lives in the ",[39,40,41],"strong",{},"filesystem",", and the impact lands squarely on the ",[39,44,45],{},"RHEL family"," — AlmaLinux, Rocky, Oracle Linux, CentOS Stream, Amazon Linux — which is where a good share of our clients' servers run.",[19,48,49,50,53,54,57,58,61,62,65,66,69],{},"On ",[39,51,52],{},"22 July",", the ",[39,55,56],{},"Qualys"," Threat Research Unit published ",[39,59,60],{},"RefluXFS (CVE-2026-64600)",". Their estimate: ",[39,63,64],{},"more than 16.4 million systems"," potentially affected. We're writing this today because of one particularly awkward property — ",[39,67,68],{},"you cannot mitigate it",". Either you patch and reboot, or you stay exposed.",[14,71,73],{"id":72},"in-one-sentence","In one sentence",[19,75,76,77,80,81,84,85,88,89,92],{},"A local user ",[39,78,79],{},"with no special privileges"," can trigger a race condition in XFS that lets them ",[39,82,83],{},"overwrite protected system files"," — ",[34,86,87],{},"\u002Fetc\u002Fpasswd"," or a SUID binary — and become ",[39,90,91],{},"root",".",[14,94,96],{"id":95},"what-actually-breaks","What actually breaks",[19,98,99,100,104,105,108],{},"XFS supports ",[101,102,103],"em",{},"reflinked"," files: two files sharing the same on-disk blocks until one of them is modified. When that happens, the kernel performs copy-on-write — it allocates a new private block, writes there, and remaps the file to point at the new block. It's the mechanism that makes ",[34,106,107],{},"cp --reflink"," instant and free until something changes.",[19,110,111,112,115,116,123,124,127,128,131],{},"The flaw sits in a crack in that process. While waiting for transaction log space, ",[39,113,114],{},"the kernel briefly drops its inode lock",". That pause is the window. If a ",[39,117,118,119,122],{},"second concurrent ",[34,120,121],{},"O_DIRECT"," write against the same reflinked file"," slips in at that moment, it completes its cycle first, remaps the file and drops the reference count. When the first writer resumes, it holds a ",[39,125,126],{},"stale reference"," and writes ",[39,129,130],{},"straight into the original block"," — the shared one it should never have touched.",[19,133,134],{},"That's the prize: if that original block belongs to a privileged file, you have just written inside it without permission to do so.",[19,136,137,138,140,141,144,145,148,149,92],{},"Qualys's proof of concept uses exactly that to surgically modify ",[34,139,87],{}," or root SUID binaries. And the changes it makes ",[39,142,143],{},"persist across reboots",", produce ",[39,146,147],{},"no kernel log output",", and ",[39,150,151],{},"bypass standard file metadata checks",[14,153,155],{"id":154},"what-makes-this-one-especially-nasty-nowhere-to-hide","What makes this one especially nasty: nowhere to hide",[19,157,158],{},"With most escalations of this kind there's some stopgap while you wait for a reboot window. With DirtyClone, disabling unprivileged user namespaces closed off the convenient exploitation path.",[19,160,161,162,165],{},"Not here. In the advisory's own words, ",[39,163,164],{},"this isn't a vulnerability you can harden around, isolate, or live-patch",". What doesn't help:",[167,168,169,176,182,188],"ul",{},[170,171,172,175],"li",{},[39,173,174],{},"SELinux in Enforcing mode",": doesn't stop it. This is the detail that stands out most in the advisory.",[170,177,178,181],{},[39,179,180],{},"seccomp",": doesn't stop it.",[170,183,184,187],{},[39,185,186],{},"KASLR",": doesn't apply; no randomisation needs defeating.",[170,189,190,181],{},[39,191,192],{},"Container isolation",[19,194,195,196,199],{},"The reason is that the exploit does nothing unusual. It uses the filesystem ",[39,197,198],{},"exactly the way it was designed to be used",": two concurrent direct writes to a reflinked file. No containment mechanism sees anything anomalous, because from its point of view there isn't any.",[19,201,202,203,92],{},"The only fix is to ",[39,204,205],{},"update the kernel and reboot",[14,207,209],{"id":208},"whos-affected","Who's affected",[19,211,212,215,216,219],{},[39,213,214],{},"Kernel versions:"," ",[39,217,218],{},"4.11 and later"," — that is, since 2017 — without the patch.",[19,221,222,225],{},[39,223,224],{},"Vulnerable out of the box"," (because they mount XFS with reflink enabled by default):",[227,228,229,242],"table",{},[230,231,232],"thead",{},[233,234,235,239],"tr",{},[236,237,238],"th",{},"Distribution",[236,240,241],{},"Versions",[243,244,245,254,261,268,275,282,290],"tbody",{},[233,246,247,251],{},[248,249,250],"td",{},"RHEL",[248,252,253],{},"8, 9, 10",[233,255,256,259],{},[248,257,258],{},"CentOS Stream",[248,260,253],{},[233,262,263,266],{},[248,264,265],{},"AlmaLinux and Rocky Linux",[248,267,253],{},[233,269,270,273],{},[248,271,272],{},"Oracle Linux",[248,274,253],{},[233,276,277,280],{},[248,278,279],{},"CloudLinux",[248,281,253],{},[233,283,284,287],{},[248,285,286],{},"Amazon Linux",[248,288,289],{},"2023, and Amazon Linux 2 AMIs from December 2022 onwards",[233,291,292,295],{},[248,293,294],{},"Fedora Server",[248,296,297],{},"31 and later",[19,299,300,303,304,307,308,311],{},[39,301,302],{},"Affected only if you went looking for it:"," Debian, Ubuntu and SUSE are ",[39,305,306],{},"not"," vulnerable in their default configuration. They only are if someone manually created an XFS filesystem with ",[34,309,310],{},"reflink=1",". If your estate is stock Debian\u002FUbuntu you can breathe out — but do check anyway, because file servers and virtualisation nodes are precisely where that gets turned on.",[19,313,314,317,318,321],{},[39,315,316],{},"Who can exploit it:"," any ",[39,319,320],{},"local user",", with no special privileges or capabilities required. In practice: shared hosting, servers with third-party SSH accounts, multi-tenant environments, CI machines running other people's jobs — anywhere someone who isn't you can execute code.",[14,323,325],{"id":324},"how-to-tell-in-two-minutes","How to tell in two minutes",[327,328,330],"h3",{"id":329},"_1-check-whether-you-use-xfs","1. Check whether you use XFS",[332,333,338],"pre",{"className":334,"code":335,"language":336,"meta":337,"style":337},"language-bash shiki shiki-themes github-dark-high-contrast","findmnt -t xfs\n","bash","",[34,339,340],{"__ignoreMap":337},[341,342,345,349,353],"span",{"class":343,"line":344},"line",1,[341,346,348],{"class":347},"s_sBn","findmnt",[341,350,352],{"class":351},"sCcAr"," -t",[341,354,356],{"class":355},"sTRMh"," xfs\n",[19,358,359,360,363],{},"Nothing returned means no XFS filesystems mounted, and this CVE isn't your problem. On RHEL 8+ and derivatives, XFS is the ",[39,361,362],{},"default filesystem",", so expect it to show up.",[327,365,367],{"id":366},"_2-check-whether-reflink-is-enabled","2. Check whether reflink is enabled",[332,369,371],{"className":334,"code":370,"language":336,"meta":337,"style":337},"sudo xfs_info \u002F | grep reflink\n",[34,372,373],{"__ignoreMap":337},[341,374,375,378,381,384,388,391],{"class":343,"line":344},[341,376,377],{"class":347},"sudo",[341,379,380],{"class":355}," xfs_info",[341,382,383],{"class":355}," \u002F",[341,385,387],{"class":386},"sWyjQ"," |",[341,389,390],{"class":347}," grep",[341,392,393],{"class":355}," reflink\n",[19,395,396,397,399,400,403,404,92],{},"Look for ",[34,398,310],{}," in the output. If it says ",[34,401,402],{},"reflink=0",", that filesystem isn't exploitable this way. Repeat for every XFS mount point from step one, not just ",[34,405,406],{},"\u002F",[327,408,410],{"id":409},"_3-check-your-kernel","3. Check your kernel",[332,412,414],{"className":334,"code":413,"language":336,"meta":337,"style":337},"uname -r\nrpm -q kernel --last | head -3\n",[34,415,416,424],{"__ignoreMap":337},[341,417,418,421],{"class":343,"line":344},[341,419,420],{"class":347},"uname",[341,422,423],{"class":351}," -r\n",[341,425,427,430,433,436,439,441,444],{"class":343,"line":426},2,[341,428,429],{"class":347},"rpm",[341,431,432],{"class":351}," -q",[341,434,435],{"class":355}," kernel",[341,437,438],{"class":351}," --last",[341,440,387],{"class":386},[341,442,443],{"class":347}," head",[341,445,446],{"class":351}," -3\n",[19,448,449,450,453],{},"The version number alone tells you little here, because each distribution backports on its own schedule. ",[39,451,452],{},"Look at the package date"," and cross-check it against your vendor's advisory.",[14,455,457],{"id":456},"what-to-do-today","What to do today",[327,459,461],{"id":460},"patch-status-honestly","Patch status, honestly",[19,463,464,465,468,469,472,473,476],{},"The fix was ",[39,466,467],{},"merged into the Linux tree on 16 July"," and distributions are backporting it. At the time of writing, ",[39,470,471],{},"not all of them have shipped packages yet",". So the first step isn't to update blindly — it's to ",[39,474,475],{},"check your distribution's security advisory for CVE-2026-64600"," and see whether a kernel is available.",[167,478,479,488,496,504,512],{},[170,480,481,482],{},"Red Hat: ",[23,483,487],{"href":484,"rel":485},"https:\u002F\u002Faccess.redhat.com\u002Fsecurity\u002Fcve\u002Fcve-2026-64600",[486],"nofollow","access.redhat.com\u002Fsecurity\u002Fcve\u002Fcve-2026-64600",[170,489,490,491],{},"AlmaLinux: ",[23,492,495],{"href":493,"rel":494},"https:\u002F\u002Ferrata.almalinux.org\u002F",[486],"errata.almalinux.org",[170,497,498,499],{},"Rocky Linux: ",[23,500,503],{"href":501,"rel":502},"https:\u002F\u002Ferrata.rockylinux.org\u002F",[486],"errata.rockylinux.org",[170,505,506,507],{},"Oracle Linux: ",[23,508,511],{"href":509,"rel":510},"https:\u002F\u002Flinux.oracle.com\u002Fsecurity",[486],"linux.oracle.com\u002Fsecurity",[170,513,514,515],{},"Amazon Linux: ",[23,516,519],{"href":517,"rel":518},"https:\u002F\u002Falas.aws.amazon.com\u002F",[486],"alas.aws.amazon.com",[327,521,523],{"id":522},"once-its-available-update-and-reboot","Once it's available: update and reboot",[332,525,527],{"className":334,"code":526,"language":336,"meta":337,"style":337},"sudo dnf update kernel\nsudo reboot\n",[34,528,529,542],{"__ignoreMap":337},[341,530,531,533,536,539],{"class":343,"line":344},[341,532,377],{"class":347},[341,534,535],{"class":355}," dnf",[341,537,538],{"class":355}," update",[341,540,541],{"class":355}," kernel\n",[341,543,544,546],{"class":343,"line":426},[341,545,377],{"class":347},[341,547,548],{"class":355}," reboot\n",[19,550,551],{},"Before rebooting, confirm which kernel will actually boot:",[332,553,555],{"className":334,"code":554,"language":336,"meta":337,"style":337},"grubby --default-kernel\n",[34,556,557],{"__ignoreMap":337},[341,558,559,562],{"class":343,"line":344},[341,560,561],{"class":347},"grubby",[341,563,564],{"class":351}," --default-kernel\n",[19,566,567,568,571],{},"Accidentally rebooting into the old kernel at three in the morning remains the classic worth avoiding. And yes: ",[39,569,570],{},"the reboot is mandatory",". There's no live patch for this one.",[327,573,575],{"id":574},"while-you-wait-for-the-package","While you wait for the package",[19,577,578,579,582],{},"There's no technical mitigation, but you can ",[39,580,581],{},"reduce who is able to try",", which is all that's left:",[167,584,585,591,597],{},[170,586,587,590],{},[39,588,589],{},"Review who holds local accounts"," on affected machines and suspend any that aren't essential for a few days.",[170,592,593,596],{},[39,594,595],{},"Prioritise by exposure",": machines with users you don't control come first.",[170,598,599,600,603,604,607],{},"If you have an XFS filesystem with reflink enabled ",[39,601,602],{},"that doesn't need it",", discuss it with your provider — but be careful, this isn't a toggle: changing ",[34,605,606],{},"reflink"," on an existing XFS filesystem is not trivial and isn't something to attempt casually in production.",[19,609,610,611,614],{},"To be clear, because it's easy to fool yourself here: ",[39,612,613],{},"none of this fixes the flaw",". It only shrinks the attack surface until the patch lands.",[327,616,618],{"id":617},"if-you-suspect-it-already-happened","If you suspect it already happened",[19,620,621,622,625,626,629],{},"Remember that this exploit ",[39,623,624],{},"leaves no kernel log trace"," and its ",[39,627,628],{},"changes survive a reboot",". It's the opposite of DirtyClone, where rebooting erased the evidence: here the evidence stays put, but it's a modified file, not an alert.",[19,631,632],{},"The obvious checks are worth running:",[332,634,636],{"className":334,"code":635,"language":336,"meta":337,"style":337},"# UID 0 accounts that shouldn't be there\nawk -F: '$3 == 0 {print $1}' \u002Fetc\u002Fpasswd\n\n# Root SUID binaries, cross-checked against what the package manager recorded\nfind \u002F -xdev -perm -4000 -user root -type f 2>\u002Fdev\u002Fnull\nrpm -Va --nomtime --nordev 2>\u002Fdev\u002Fnull | grep '^..5'\n",[34,637,638,644,658,665,671,706],{"__ignoreMap":337},[341,639,640],{"class":343,"line":344},[341,641,643],{"class":642},"sQrFR","# UID 0 accounts that shouldn't be there\n",[341,645,646,649,652,655],{"class":343,"line":426},[341,647,648],{"class":347},"awk",[341,650,651],{"class":351}," -F:",[341,653,654],{"class":355}," '$3 == 0 {print $1}'",[341,656,657],{"class":355}," \u002Fetc\u002Fpasswd\n",[341,659,661],{"class":343,"line":660},3,[341,662,664],{"emptyLinePlaceholder":663},true,"\n",[341,666,668],{"class":343,"line":667},4,[341,669,670],{"class":642},"# Root SUID binaries, cross-checked against what the package manager recorded\n",[341,672,674,677,679,682,685,688,691,694,697,700,703],{"class":343,"line":673},5,[341,675,676],{"class":347},"find",[341,678,383],{"class":355},[341,680,681],{"class":351}," -xdev",[341,683,684],{"class":351}," -perm",[341,686,687],{"class":351}," -4000",[341,689,690],{"class":351}," -user",[341,692,693],{"class":355}," root",[341,695,696],{"class":351}," -type",[341,698,699],{"class":355}," f",[341,701,702],{"class":386}," 2>",[341,704,705],{"class":355},"\u002Fdev\u002Fnull\n",[341,707,709,711,714,717,720,722,725,727,729],{"class":343,"line":708},6,[341,710,429],{"class":347},[341,712,713],{"class":351}," -Va",[341,715,716],{"class":351}," --nomtime",[341,718,719],{"class":351}," --nordev",[341,721,702],{"class":386},[341,723,724],{"class":355},"\u002Fdev\u002Fnull",[341,726,387],{"class":386},[341,728,390],{"class":347},[341,730,731],{"class":355}," '^..5'\n",[19,733,734,735,738,739,742],{},"That last command compares installed files against the hashes RPM recorded. Because ",[39,736,737],{},"the on-disk file genuinely does change"," with this flaw, ",[34,740,741],{},"rpm -Va"," is a properly useful tool here. If a privileged binary shows an altered hash and no update explains it, treat the machine as compromised: rotate credentials and keys before anything else.",[14,744,746],{"id":745},"what-were-doing","What we're doing",[19,748,749,750,753],{},"The order we're following on the machines we manage is the usual one, sorted by ",[39,751,752],{},"who can execute code on them",":",[755,756,757,763,769],"ol",{},[170,758,759,762],{},[39,760,761],{},"Servers with third-party local accounts",": shared hosting, client SFTP, multi-tenant environments. These already have a potential attacker on the inside.",[170,764,765,768],{},[39,766,767],{},"CI and container nodes",": where code we didn't write runs.",[170,770,771,774],{},[39,772,773],{},"Single-admin VPS",": minimal local surface, last in line.",[19,776,777],{},"In parallel, we've inventoried which machines mount XFS with reflink so we're not checking blind. The ones that don't simply aren't part of this round.",[14,779,781],{"id":780},"the-takeaway","The takeaway",[19,783,784],{},"RefluXFS can't be fired from the internet: it needs a local account. If you're the only person who touches your servers, the real risk is low and it can wait for your normal maintenance window.",[19,786,787,788,791],{},"But if there are users on your machines you don't fully control, this one is worth stepping outside the usual calendar for, and for one very specific reason: ",[39,789,790],{},"it's one of the few where the answer to \"can I do anything in the meantime?\" is no",". Not SELinux, not containers, not configuration hardening. Only the patch.",[19,793,794],{},"And the underlying lesson is the same as every time one of these lands: check the kernel version, check the last reboot date, update, reboot, verify. If your patching plan today amounts to \"whenever I remember\", let's talk.",[14,796,798],{"id":797},"references","References",[167,800,801,808,815,822],{},[170,802,803],{},[23,804,807],{"href":805,"rel":806},"https:\u002F\u002Fblog.qualys.com\u002Fvulnerabilities-threat-research\u002F2026\u002F07\u002F22\u002Frefluxfs-a-linux-kernel-local-privilege-escalation-to-root-in-xfs-cve-2026-64600",[486],"RefluXFS: A Linux Kernel Local Privilege Escalation to Root in XFS (CVE-2026-64600) — Qualys Threat Research Unit",[170,809,810],{},[23,811,814],{"href":812,"rel":813},"https:\u002F\u002Fsecurityonline.info\u002Frefluxfs-cve-2026-64600-xfs-root\u002F",[486],"RefluXFS CVE-2026-64600: XFS Root Privilege Escalation Hits 16.4M Systems — SecurityOnline",[170,816,817],{},[23,818,821],{"href":819,"rel":820},"https:\u002F\u002Fcybersecuritynews.com\u002Frefluxfs-linux-kernel-vulnerability\u002F",[486],"RefluXFS Linux Kernel Vulnerability Lets Attackers Gain Root Access — Cyber Security News",[170,823,824],{},[23,825,827],{"href":484,"rel":826},[486],"CVE-2026-64600 — Red Hat Customer Portal",[829,830,831],"style",{},"html pre.shiki code .s_sBn, html code.shiki .s_sBn{--shiki-default:#FFB757}html pre.shiki code .sCcAr, html code.shiki .sCcAr{--shiki-default:#91CBFF}html pre.shiki code .sTRMh, html code.shiki .sTRMh{--shiki-default:#ADDCFF}html .default .shiki span {color: var(--shiki-default);background: var(--shiki-default-bg);font-style: var(--shiki-default-font-style);font-weight: var(--shiki-default-font-weight);text-decoration: var(--shiki-default-text-decoration);}html .shiki span {color: var(--shiki-default);background: var(--shiki-default-bg);font-style: var(--shiki-default-font-style);font-weight: var(--shiki-default-font-weight);text-decoration: var(--shiki-default-text-decoration);}html pre.shiki code .sWyjQ, html code.shiki .sWyjQ{--shiki-default:#FF9492}html pre.shiki code .sQrFR, html code.shiki .sQrFR{--shiki-default:#BDC4CC}",{"title":337,"searchDepth":426,"depth":426,"links":833},[834,835,836,837,838,839,844,850,851,852],{"id":16,"depth":426,"text":17},{"id":72,"depth":426,"text":73},{"id":95,"depth":426,"text":96},{"id":154,"depth":426,"text":155},{"id":208,"depth":426,"text":209},{"id":324,"depth":426,"text":325,"children":840},[841,842,843],{"id":329,"depth":660,"text":330},{"id":366,"depth":660,"text":367},{"id":409,"depth":660,"text":410},{"id":456,"depth":426,"text":457,"children":845},[846,847,848,849],{"id":460,"depth":660,"text":461},{"id":522,"depth":660,"text":523},{"id":574,"depth":660,"text":575},{"id":617,"depth":660,"text":618},{"id":745,"depth":426,"text":746},{"id":780,"depth":426,"text":781},{"id":797,"depth":426,"text":798},"2026-07-23","Qualys published RefluXFS yesterday: a race condition in the XFS filesystem that lets any local user overwrite protected files and become root. It hits RHEL, AlmaLinux, Rocky, Oracle Linux and Amazon Linux from kernel 4.11 onwards. There is no mitigation — only patch and reboot. Here's how to tell in two minutes whether it affects you.","md","\u002Fog\u002Fog-default.png",{},"refluxfs-cve-2026-64600-root-xfs-kernel-linux","\u002Fen\u002Fblog\u002Frefluxfs-cve-2026-64600-xfs-root-linux-kernel",{"title":8,"description":854},"en\u002Fblog\u002Frefluxfs-cve-2026-64600-xfs-root-linux-kernel",[863,864,865,866],"Security","Linux","Servers","CVE","xQO5W38C_O0Rn_JYDc8f6IsnwAVLqd4nH9gGsXY1Hz0",1784782834731]