RefluXFS (CVE-2026-64600): root en 16 millones de servidores por un fallo en XFS, y SELinux no te salva

Esta vez le toca a la familia Red Hat

Las últimas escaladas a root de las que hemos escrito aquí —DirtyClone, ssh-keysign-pwn— venían por el lado del stack de red o de ptrace, y el aviso gordo lo sacaba Canonical. Esta es distinta en dos cosas que importan: está en el sistema de ficheros, y el impacto se concentra en la familia RHEL —AlmaLinux, Rocky, Oracle Linux, CentOS Stream, Amazon Linux—, que es donde vive buena parte de los servidores de nuestros clientes.

El 22 de julio, la unidad de investigación de Qualys publicó RefluXFS (CVE-2026-64600). Su estimación es que hay más de 16,4 millones de sistemas potencialmente afectados. Lo escribimos hoy porque tiene una particularidad incómoda: no se puede mitigar. O parcheas y reinicias, o sigues expuesto.

En una frase

Un usuario local sin ningún privilegio especial puede provocar una condición de carrera en XFS que le permite sobrescribir ficheros protegidos del sistema —/etc/passwd o un binario SUID— y con eso convertirse en root.

Qué falla exactamente

XFS admite ficheros reflinked: dos ficheros que comparten los mismos bloques en disco hasta que uno de los dos se modifica. Cuando eso ocurre, el kernel aplica copy-on-write: reserva un bloque nuevo y privado, escribe ahí, y reasigna el fichero para que apunte al bloque nuevo. Es el mecanismo que hace que cp --reflink sea instantáneo y no ocupe espacio hasta que hay cambios.

El fallo está en una grieta de ese proceso. Mientras espera espacio en el log de transacciones, el kernel suelta brevemente el bloqueo del inodo. Esa pausa es la ventana. Si en ese instante entra una segunda escritura O_DIRECT concurrente sobre el mismo fichero reflinked, esa segunda escritura completa su ciclo antes, reasigna el fichero y decrementa el contador de referencias. Cuando el primer escritor retoma el control, se encuentra con una referencia obsoleta y escribe directamente sobre el bloque original —el compartido, el que no debía tocar—.

Ahí está el premio: si ese bloque original pertenece a un fichero privilegiado, acabas de escribir dentro de él sin tener permiso para hacerlo.

La prueba de concepto de Qualys aprovecha exactamente eso para modificar quirúrgicamente /etc/passwd o binarios SUID de root. Y los cambios que hace persisten tras el reinicio, no generan ninguna traza en el log del kernel y esquivan las comprobaciones habituales de metadatos de ficheros.

Lo que hace a este especialmente feo: no hay dónde esconderse

Con la mayoría de estas escaladas hay algún paliativo mientras llega la ventana de reinicio. Con DirtyClone, sin ir más lejos, desactivar los espacios de nombres de usuario sin privilegios cerraba la vía cómoda de explotación.

Aquí no. En palabras del propio aviso, esta no es una vulnerabilidad alrededor de la cual puedas fortificarte, aislarte o aplicar parcheo en caliente. Lo que no sirve:

• SELinux en modo Enforcing: no lo detiene. Este es el dato que más llama la atención del aviso.
• seccomp: no lo detiene.
• KASLR: no aplica; no hace falta saltarse ninguna aleatorización.
• Aislamiento de contenedores: no lo detiene.

La razón es que el exploit no hace nada raro. Usa el sistema de ficheros exactamente como está diseñado para usarse: dos escrituras directas concurrentes sobre un fichero reflinked. Ningún mecanismo de contención ve nada anómalo porque, desde su punto de vista, no lo hay.

La única solución es actualizar el kernel y reiniciar.

A quién afecta

Versiones de kernel: de la 4.11 en adelante —es decir, desde 2017— que no lleven el parche.

Distribuciones vulnerables de serie (porque montan XFS con reflink activado por defecto):

Distribuciones afectadas solo si te lo has buscado: Debian, Ubuntu y SUSE no son vulnerables con su configuración por defecto. Solo lo son si alguien montó a mano un XFS con reflink=1. Si tu parque es Debian/Ubuntu estándar, respira — pero comprueba, que los servidores de ficheros y los nodos de virtualización son justo donde se suele activar.

Quién puede explotarlo: cualquier usuario local, sin privilegios especiales ni capacidades concretas. Traducido: hosting compartido, servidores con cuentas SSH de terceros, entornos multi-tenant, máquinas de CI con trabajos de terceros, cualquier sitio donde alguien que no eres tú pueda ejecutar código.

Cómo saber en dos minutos si te toca

1. Mira si usas XFS

findmnt -t xfs

Si no devuelve nada, no tienes sistemas de ficheros XFS montados y este CVE no va contigo. En RHEL 8+ y derivados, XFS es el sistema de ficheros por defecto, así que lo normal es que sí aparezca.

2. Comprueba si reflink está activo

sudo xfs_info / | grep reflink

Busca reflink=1 en la salida. Si pone reflink=0, ese sistema de ficheros no es explotable por esta vía. Repite la comprobación para cada punto de montaje XFS que te haya salido en el paso anterior, no solo para /.

3. Mira tu kernel

uname -r
rpm -q kernel --last | head -3

El número por sí solo no te dice nada útil aquí, porque cada distribución hace su propio backport. Fíjate en la fecha del paquete y contrástala con el aviso de tu proveedor.

Qué tienes que hacer hoy

Estado del parche, con honestidad

El arreglo se integró en el árbol de Linux el 16 de julio y las distribuciones están haciendo backport. A la hora de escribir esto, no todas han publicado todavía sus paquetes. Así que el primer paso no es actualizar a ciegas: es ir al aviso de seguridad de tu distribución para CVE-2026-64600 y ver si ya hay kernel disponible.

• Red Hat: access.redhat.com/security/cve/cve-2026-64600
• AlmaLinux: errata.almalinux.org
• Rocky Linux: errata.rockylinux.org
• Oracle Linux: linux.oracle.com/security
• Amazon Linux: alas.aws.amazon.com

Cuando esté disponible: actualizar y reiniciar

sudo dnf update kernel
sudo reboot

Antes de reiniciar, confirma cuál va a arrancar:

grubby --default-kernel

Reiniciar por error al kernel viejo a las tres de la madrugada sigue siendo el clásico que conviene evitar. Y sí: el reinicio es obligatorio. No hay parcheo en caliente que valga para este.

Mientras esperas al paquete

No hay mitigación técnica, pero sí puedes reducir quién puede intentarlo, que es lo único que queda:

• Revisa quién tiene cuenta local en las máquinas afectadas y suspende las que no sean imprescindibles estos días.
• Prioriza por exposición: primero las máquinas con usuarios que no controlas.
• Si tienes un sistema de ficheros XFS con reflink activado que no necesitas que lo tenga, valóralo con tu proveedor — pero ojo, no es un interruptor: cambiar reflink en un XFS ya creado no es trivial y no lo hagas a la ligera en producción.

Que quede claro, porque aquí es fácil autoengañarse: nada de esto arregla el fallo. Solo reduce la superficie mientras llega el parche.

Si sospechas que ya te ha pasado

Recuerda que este exploit no deja rastro en el log del kernel y los cambios sobreviven al reinicio. Es lo contrario de DirtyClone, donde un reinicio borraba la evidencia: aquí la evidencia se queda, pero es un fichero modificado, no una alerta.

Merece la pena mirar lo obvio:

# Cuentas con UID 0 que no deberían estar
awk -F: '$3 == 0 {print $1}' /etc/passwd

# Binarios SUID de root, contrastados con lo que dice el paquete
find / -xdev -perm -4000 -user root -type f 2>/dev/null
rpm -Va --nomtime --nordev 2>/dev/null | grep '^..5'

Ese último comando compara los ficheros instalados con los hashes que registró RPM. Como aquí el fichero en disco sí cambia, rpm -Va es una herramienta útil de verdad para este CVE. Si aparece un binario privilegiado con el hash alterado y no hay una actualización que lo explique, trata la máquina como comprometida: rota credenciales y claves antes de nada.

Lo que hacemos nosotros

El orden que estamos siguiendo estos días en las máquinas que gestionamos es el de siempre, ordenado por quién puede ejecutar código en ellas:

1. Servidores con cuentas locales de terceros: hosting compartido, SFTP de clientes, entornos multi-tenant. Son los que tienen un atacante potencial ya dentro.
2. Nodos de CI y de contenedores: donde corre código que no escribimos nosotros.
3. VPS de administrador único: superficie local mínima, van al final.

En paralelo, hemos inventariado qué máquinas montan XFS con reflink para no ir revisando a ciegas. Las que no lo montan, sencillamente no entran en esta ronda.

Qué nos llevamos

RefluXFS no se dispara desde internet: hace falta una cuenta local. Si tus servidores solo los tocas tú, el riesgo real es bajo y puedes esperar a la ventana de mantenimiento normal.

Pero si en tus máquinas hay usuarios que no controlas al cien por cien, este merece salirse del calendario habitual, y por un motivo muy concreto: es de los pocos donde la respuesta a «¿puedo hacer algo mientras tanto?» es que no. Ni SELinux, ni contenedores, ni endurecer configuraciones. Solo el parche.

Y la conclusión de fondo es la de cada vez que sale una de estas: mirar la versión del kernel, mirar la fecha del último reinicio, actualizar, reiniciar y verificar. Si tu plan de parcheo a día de hoy consiste en «cuando me acuerde», hablamos.

Referencias

• RefluXFS: A Linux Kernel Local Privilege Escalation to Root in XFS (CVE-2026-64600) — Qualys Threat Research Unit
• RefluXFS CVE-2026-64600: XFS Root Privilege Escalation Hits 16.4M Systems — SecurityOnline
• RefluXFS Linux Kernel Vulnerability Lets Attackers Gain Root Access — Cyber Security News
• CVE-2026-64600 — Red Hat Customer Portal