RefluXFS: root en Linux por una race condition en XFS

En pocas palabras: RefluXFS (CVE-2026-64600) es una race condition en el copy-on-write de XFS que Qualys publicó el 22 de julio de 2026. Le da root a cualquier usuario local en RHEL, Oracle Linux, Amazon Linux y Fedora con reflink activado, incluso con SELinux en enforcing.

Qualys publicó el 22 de julio de 2026 los detalles de RefluXFS (CVE-2026-64600), una vulnerabilidad de escalada de privilegios en Linux que le entrega root a cualquier usuario local sin privilegios en sistemas con raíz XFS y reflink activado, incluso con SELinux en modo enforcing y sin dejar rastro en los logs del kernel.

RefluXFS es una race condition en la ruta copy-on-write del filesystem XFS del kernel Linux, identificada como CVE-2026-64600 y descubierta por el Threat Research Unit de Qualys. Con ella, un proceso que corre bajo una cuenta local común sobrescribe a nivel de capa de bloques cualquier archivo que pueda leer en un volumen XFS, y ese primitivo se convierte de forma directa en privilegios de root sobre el host.

¿Cómo funciona la race condition de XFS que hace posible RefluXFS?

RefluXFS explota una ventana de carrera entre dos escrituras concurrentes con O_DIRECT sobre un archivo con reflink. En la ruta de asignación copy-on-write del kernel se abre una ventana en la que se suelta el lock. En ese hueco, una de esas escrituras deja de aterrizar en el almacenamiento propio del atacante y termina cayendo en el bloque físico que todavía respalda el archivo original.

Traducido a lo que importa: escribís en tu propio archivo y el dato termina en el bloque físico de otro. Ya lo cubrimos antes en si administras Linux en DevOps.

Ponele que tenés acceso de lectura a un binario SUID o a un archivo de configuración que corre como root (cosa que en cualquier sistema es la norma, no la excepción). Con ese permiso de lectura alcanza. Copiás el archivo con reflink, disparás la carrera, y lo que escribís queda pisando el contenido real en disco. De ahí a root hay un paso, y es corto.

¿Qué distribuciones y versiones de kernel están afectadas?

Está afectada cualquier distribución Linux que use XFS como filesystem raíz con reflink habilitado. El aviso de Qualys nombra en particular a RHEL, Oracle Linux, Amazon Linux y Fedora, todas en su instalación por defecto. El bug vive en el kernel desde que XFS incorporó reflink en la serie 4.11 (2017), lo que le da a esta falla unos nueve años de antigüedad, según la cobertura de The Hacker News.

Qualys confirmó la explotación sobre una instalación por defecto de Fedora Server 44.

Escenario	Filesystem raíz típico	reflink por defecto	Situación frente a RefluXFS
RHEL 8 / 9 / 10	XFS	Sí	Vulnerable hasta parchear
Fedora Server 44	XFS	Sí	Explotación confirmada por Qualys
Oracle Linux / Amazon Linux	XFS	Sí	Vulnerable hasta parchear
Debian / Ubuntu con ext4	ext4	No aplica	Fuera del alcance del exploit
Cualquier distro con XFS armado a mano	XFS	Depende del formateo	Verificar con xfs_info

¿Cómo saber si tu servidor es vulnerable a RefluXFS?

Tres chequeos de treinta segundos alcanzan para saber en qué lado estás. Si los tres dan positivo, tu host es vulnerable hasta que apliques el kernel parcheado y reinicies. No hay una cuarta condición ni un requisito exótico que te salve.

• Confirmá que la raíz es XFS: df -T / y mirá la columna de tipo.
• Confirmá que reflink está activo: xfs_info / y buscá reflink=1 en la línea de datos.
• Confirmá la versión de kernel: uname -r. De 4.11 en adelante, y sin el parche del vendor aplicado, estás dentro del rango.

¿Por qué SELinux en enforcing no detiene esta escalada de privilegios en Linux?

SELinux no lo frena porque el ataque no pasa por la ruta que SELinux vigila. La política evalúa operaciones a nivel de VFS: quién abre qué archivo, con qué contexto, para qué. RefluXFS actúa por debajo, en la capa de bloques, sobrescribiendo el contenido físico de un archivo que el atacante tenía permiso de leer. Desde la óptica de la política, nunca hubo una violación. Cubrimos ese tema en detalle en automatizar la entrega de parches.

Lo mismo pasa con los controles que dependen de detectar “algo raro” en el kernel. El aviso de Qualys es explícito en que la explotación no genera salida en el log del kernel. Ojo con esto si tu esquema de detección se apoya en dmesg o en alertas de auditd sobre accesos denegados: no hay denegaciones que puedan detectarse, porque técnicamente el atacante hizo todo lo que tenía derecho a hacer.

¿Qué impacto real tiene un exploit exitoso?

Root en el host, sin contraseña, con persistencia que sobrevive al reboot si el atacante pisó un binario o un archivo de arranque. La cadena típica en un incidente real es la que ya conocemos: alguien entra por una vulnerabilidad de aplicación, cae con los permisos del usuario web, y hasta ayer se quedaba trabado ahí. Con RefluXFS, ese punto muerto se convierte en control total de la máquina.

¿Y en entornos multiusuario? Ahí es donde duele de verdad. Servidores de desarrollo con shells compartidas, nodos de CI donde los jobs corren como usuario común, hosting con cuentas SFTP, cualquier lugar donde varias personas o procesos comparten el mismo kernel pasa de “riesgo contenido” a “un solo actor toma todo”.

Si tercerizás la infraestructura, la consulta al soporte es puntual: cuándo aplican el kernel parcheado y si el reinicio lo coordinan ellos o vos. En un VPS o servidor dedicado de donweb.com, esa ventana de mantenimiento la definís con el proveedor, y conviene agendarla ahora y no cuando aparezca el primer exploit público circulando.

¿Cómo se parchea RefluXFS?

Kernel actualizado más reinicio. No hay mitigación intermedia, no hay flag que puedas apagar en caliente, no hay regla de seccomp que te compre tiempo. Red Hat publicó erratas de kernel para sus versiones soportadas y documentó el caso en su portal de soluciones; CloudLinux mantiene un tracker de estado por versión para sus kernels.

El procedimiento es el de siempre (yum update kernel o dnf update kernel, después reboot), y la parte difícil no es técnica: es conseguir la parada planificada. Desactivar reflink no es una salida realista, porque es una propiedad del filesystem que se define al formatear. En infraestructura crítica en Linux profundizamos sobre esto.

¿Qué tuvo que ver un modelo de IA con el hallazgo?

La vulnerabilidad la encontró un modelo de Anthropic, Claude Mythos Preview, dentro del flujo de auditoría manual de Qualys y con revisión humana en cada paso. En el aviso enviado a la lista oss-security, el equipo cuenta que apuntó el modelo al kernel Linux y, en sus palabras, le pidió “que encontrara una vulnerabilidad similar a Dirty COW”.

Las primeras pasadas no dieron nada. Ahí refinaron el prompt en tres etapas: primero acotaron a race conditions, después a los directorios mm/ y fs/, y por último a los filesystems dentro de fs/*/. Tras varias iteraciones el modelo encontró la carrera en XFS y escribió una prueba de concepto que escalaba a root, que los investigadores revisaron y probaron contra una instalación por defecto de Fedora Server 44.

Vale la pena leer eso dos veces si tu modelo mental de la “IA de seguridad” todavía es el de un chatbot que resume CVEs.

Esto se conecta con nuestro análisis de Linux kernel vulnerabilities, donde cubrimos el tema en detalle.

Errores comunes al responder a RefluXFS

• Confiar en que SELinux te cubre. El aviso de Qualys aclara que la escalada funciona con SELinux en enforcing. Si tu plan de mitigación era ese, no tenés plan.
• Actualizar el paquete y no reiniciar. yum update kernel deja el kernel nuevo en disco, pero seguís corriendo el viejo hasta el reboot. Verificá con uname -r después de reiniciar, no antes.
• Asumir que sin usuarios humanos no hay riesgo. Cuentas de servicio, procesos PHP-FPM, runners de CI y cualquier proceso comprometido cuentan como “usuario local sin privilegios”.
• Buscar evidencia de explotación en los logs del kernel. No la vas a encontrar: el exploit no genera salida. Priorizá el parche por sobre la caza de indicadores.

Preguntas Frecuentes

¿Qué es CVE-2026-64600?

Es el identificador de RefluXFS, una race condition en la ruta copy-on-write del filesystem XFS del kernel Linux que permite escalada local de privilegios hasta root. La publicó el Threat Research Unit de Qualys el 22 de julio de 2026. Cobertura relacionada: el futuro del kernel Linux.

¿Se puede explotar RefluXFS de forma remota?

No. Requiere ejecución de código local con una cuenta sin privilegios en el sistema afectado. Eso baja el riesgo de exposición directa a internet, pero la convierte en una pieza ideal para la segunda etapa de un ataque que ya logró entrar por otra vía. Tema relacionado: más recursos sobre seguridad Linux.

¿Mi servidor Ubuntu o Debian está afectado?

Solo si armaste la raíz sobre XFS con reflink habilitado, cosa que no es el default en esas distribuciones (usan ext4). Confirmalo con df -T / y xfs_info / antes de darlo por descartado, sobre todo en servidores heredados o en imágenes de nube personalizadas.

¿Hay algún workaround que evite reiniciar?

No existe workaround soportado. El remedio es instalar el kernel corregido por tu distribución y reiniciar. Deshabilitar reflink no es viable en un sistema en producción porque es una propiedad definida al formatear el filesystem.

¿Desde qué versión de kernel existe el bug?

Desde que XFS incorporó reflink en la serie 4.11, en 2017, lo que ubica la falla en unos nueve años de vida dentro del kernel. Cualquier kernel posterior a esa línea, sin el parche del vendor, entra en el rango afectado.

Conclusión

Lo que cambió esta semana es concreto: si tu flota corre RHEL, Fedora, Oracle Linux o Amazon Linux con XFS de raíz, cualquier cuenta local en esos hosts es hoy una cuenta de root en potencia, y ni SELinux ni tus logs te van a avisar. El PoC ya existe y está probado.

El plan de acción de esta semana cabe en tres líneas: corré df -T / y xfs_info / en todo el inventario para saber qué hosts entran, agendá la ventana de reinicio con el equipo o con tu proveedor, y priorizá los servidores multiusuario y los nodos de CI por sobre los que corren un solo servicio aislado.

El dato de fondo, el que se va a discutir durante meses, es cómo apareció: un modelo revisando fs/*/ encontró en semanas algo que estuvo nueve años a la vista de todos. Esa capacidad la van a tener los dos lados del mostrador.

Fuentes

• Qualys TRU – Análisis técnico original de RefluXFS (CVE-2026-64600)
• oss-security – Aviso de seguridad de Qualys enviado a la lista pública
• Red Hat – Documentación de la vulnerabilidad y erratas de kernel
• CloudLinux – Tracker de estado de parches por versión de kernel
• BleepingComputer – Cobertura del hallazgo y su alcance
• The Hacker News – Contexto sobre la antigüedad de la falla