Una nueva vulnerabilidad de RefluXFS en Linux resiste los reinicios y elude los registros

En directo esta tarde: Analizaremos RefluXFS con un experto en parches de Linux, incluyendo las últimas medidas adoptadas por los fabricantes y cómo solucionar el problema sin necesidad de reiniciar el sistema. Míralo aquí →

La versión resumida

Ir a la versión completa ↓

En qué consiste: RefluXFS, registrado como CVE-2026-64600, es una condición de carrera en la ruta de «copia al escribir» (copy-on-write) del sistema de archivos XFS del núcleo de Linux. Permite a un usuario local sin privilegios redirigir una operación de escritura desde una copia con enlace simbólico de vuelta al bloque físico del disco del archivo original, de modo que un atacante puede alterar un archivo propiedad de root al que tiene permiso de lectura, pero no de escritura. Ir a la versión completa →

Impacto: Escalada de privilegios locales a root. Qualys lo demostró con el archivo /etc/passwd y los binarios setuid-root en un sistema Linux empresarial predeterminado, eliminando la protección mediante contraseña de la cuenta root en un sistema RHEL 10.2 de serie en cuestión de segundos. La escritura se realiza por debajo de la ruta normal de escritura de inodos, por lo que puede conservar el propietario, los permisos, las marcas de tiempo y el bit setuid del objetivo, sobrevive a un reinicio y, en las pruebas de Qualys, no generó ninguna entrada en el registro del kernel. Ir a la versión completa →

Gravedad: En el momento de redactar este informe, no se había confirmado ninguna puntuación CVSS pública. En cualquier caso, considérala de alta prioridad: la explotación es fiable, solo requiere una cuenta local normal, elude las medidas de seguridad habituales y proporciona privilegios de root persistentes. Red Hat la clasifica como «Importante». Ir a la versión completa →

Quiénes se ven afectados: los núcleos de Linux basados en la versión 4.11 o posteriores que contengan el código XFS vulnerable y no incluyan la corrección, en un sistema de archivos XFS creado con soporte para reflink, en el que un archivo protegido de solo lectura y un directorio en el que un atacante pueda escribir compartan dicho sistema de archivos. Esto describe la configuración predeterminada en RHEL, CentOS Stream, Oracle Linux, Rocky Linux, AlmaLinux y CloudLinux 8, 9 y 10, además de Fedora Server 31 y versiones posteriores, Amazon Linux 2023 y las imágenes de Amazon Linux 2 a partir de diciembre de 2022. RHEL 7 es anterior a XFS reflink y queda fuera del ámbito de exposición predeterminado. Ir a la versión completa →

Estado: Divulgado públicamente por Qualys el 22 de julio de 2026 y detectado con ayuda de IA en el marco del Proyecto Glasswing de Anthropic. La corrección en el código fuente se incorporó el 16 de julio, y los proveedores han lanzado núcleos retrocompatibles. Algunas correcciones para empresas se publicaron antes de la divulgación como actualizaciones normales del núcleo, por lo que es posible que un host ya cuente con la corrección aunque la actualización no mencione el CVE-2026-64600. Ir a la versión completa →

Hazlo ahora: no existe ninguna solución alternativa de configuración sin riesgos. Red Hat ha publicado una medida de mitigación temporal mediante SystemTap, pero la solución definitiva es un núcleo parcheado: comprueba si cada sistema de archivos XFS utiliza enlaces de referencia, aplica el núcleo corregido correspondiente a tu versión concreta y reinicia el sistema, o bien aplica un parche de KernelCare que no requiera reinicio (que se implementa automáticamente para los usuarios en segundo plano). Ir a la versión completa →

xfs_info / | grep reflink=

Un resultado de «reflink=1» confirma que se cumple el requisito previo del sistema de archivos. Repite el proceso con los demás volúmenes XFS montados que contengan tanto archivos protegidos como directorios en los que un atacante pueda escribir.

RefluXFS incumple una de las promesas más básicas del sistema de archivos: que el hecho de poder leer un archivo protegido no te permite reescribirlo.

El atacante nunca abre el archivo /etc/passwd ni un binario con setuid-root en modo de escritura. Linux lo denegaría de inmediato. En su lugar, le pide a XFS que cree una copia con enlace simbólico del archivo en algún lugar bajo su control y, a continuación, realiza dos escrituras simultáneas en esa copia. Debido a una asignación de bloques obsoleta dentro del núcleo, una de esas escrituras puede acabar en el archivo original protegido en lugar de en la copia. El atacante escribe en un archivo que controla, pero el original, propiedad de root, se modifica.

Esa única vulnerabilidad basta para borrar la contraseña de root, reescribir los datos de autenticación o introducir código malicioso en un binario con setuid-root para que se ejecute como root. En una instalación predeterminada de RHEL 10.2, Qualys lo consiguió en cuestión de segundos.

Hay un detalle en el que merece la pena detenerse, sobre todo en lo que respecta al debate de la retransmisión en directo. RefluXFS se descubrió en el marco del Proyecto Glasswing de Anthropic: Qualys señaló el kernel a Claude Mythos Preview y le pidió que buscara una carrera de tipo «Dirty COW»; a continuación, sus propios investigadores reprodujeron el hallazgo, verificaron cada afirmación y llevaron a cabo la divulgación coordinada. La IA aceleró la búsqueda; los humanos lo confirmaron y lo dieron a conocer. Hágalo como un anticipo de hacia dónde se dirige la detección de errores en el kernel, no como una explotación «a pulso».

Hay dos cosas que aún te incitarán a clasificar esto como un problema de baja prioridad. La primera es la redacción de la actualización original del proveedor, que se presentó como una simple corrección de «corrupción de datos en XFS» y da la impresión de ser un simple inconveniente relacionado con la integridad de los datos. Se trata de una primitiva de raíz local fiable. La segunda es el propio reflink, que suena como una opción exótica que nadie activa. Lleva años siendo el valor predeterminado de mkfs en el sistema de archivos raíz de la familia RHEL, por lo que en un equipo de serie ya cumples la condición sin siquiera preguntarlo.

Los enlaces referenciales de XFS permiten que dos archivos apunten a los mismos bloques físicos del disco sin duplicar los datos. Cuando se escribe en un archivo, XFS lleva a cabo la copia en el momento de la escritura: asigna un nuevo bloque para el archivo modificado, copia los datos, reasigna ese archivo y reduce el recuento de referencias del bloque original. Se supone que el archivo original permanece intacto.

RefluXFS es lo que ocurre cuando dos operaciones de escritura compiten por esa secuencia.

[Attacker reflink-clones a readable root-owned file]
                     |
                     v
[Both files temporarily reference the same disk blocks]
                     |
                     v
[Two concurrent O_DIRECT writes race against the clone]
                     |
                     v
[XFS drops the inode lock to reserve transaction space]
                     |
                     v
[One path keeps using a stale physical block mapping]
                     |
                     v
[The write reaches the original protected file's disk block]
                     |
                     v
[Protected file changes with no normal write to its inode]

El código vulnerable lee la rama de datos del archivo bajo el bloqueo del inodo y, a continuación, libera el bloqueo para reservar espacio en el registro de transacciones. Durante ese intervalo, un segundo escritor puede completar su propio ciclo de «copia al escribir», reasignar el clon a un bloque nuevo y reducir el recuento de referencias del bloque original a uno. Cuando el primer escritor vuelve a adquirir el bloqueo, comprueba de nuevo si el bloque sigue siendo compartido, pero lo hace comparando la dirección física que capturó antes de que se liberara el bloqueo. Esa dirección corresponde a una asignación obsoleta de la rama de datos. XFS detecta un recuento de uno, concluye que el bloque es privado y escribe en él, a pesar de que ese bloque ahora pertenece únicamente al archivo de origen protegido.

Dado que O_DIRECT omite la caché de páginas, no se produce ninguna revalidación y la escritura se realiza directamente en el disco. Se trata de una carrera entre el momento de la comprobación y el momento del uso a lo largo de un ciclo de bloqueo de inodo. La comprobación de permisos nunca fue errónea. El núcleo simplemente actuó sobre una dirección de bloque que había quedado obsoleta.

La corrección hace que XFS vuelva a leer la asignación del data-fork tras detectar que dicha asignación podría haber cambiado mientras el bloqueo estaba liberado:

Before:
read mapping -> release lock -> mapping changes -> reuse stale mapping -> wrong file overwritten

After:
read mapping -> release lock -> mapping changes -> reread mapping -> write follows current mapping

El informe de Qualys localiza la pérdida del bloqueo en la función xfs_reflink_allocate_cow(). La incorporación a la rama principal, titulada «xfs: remuestrear la asignación de la rama de datos tras el ciclo de ILOCK», se fusionó el 16 de julio y remuestrea la asignación en las funciones auxiliares de CoW afectadas. No modifica el formato en disco ni la estructura de datos del núcleo, lo cual resultará importante más adelante para la aplicación de parches sin necesidad de reiniciar el sistema.

La sobrescritura se produce en el nivel de bloque y omite la ruta de escritura habitual a nivel de inodo del archivo protegido. Esto anula varias señales que se utilizan habitualmente para detectar cambios en los archivos:

• El destino conserva su propietario y modo de permisos originales.
• Su bit setuid permanece activo, por lo que un binario setuid-root manipulado sigue ejecutándose como root.
• No es necesario que sus marcas de tiempo reflejen el cambio.
• Es posible que la supervisión de la actividad de los archivos basada en rutas no registre una operación de escritura en el propio destino protegido.
• Los datos modificados permanecen en el disco tras reiniciar el sistema.
• Qualys no detectó ninguna advertencia ni entrada de registro correspondiente en el núcleo.

Por eso RefluXFS es peor que un error transitorio de corrupción de memoria. Se trata de una primitiva de modificación persistente en el disco que no altera la mayoría de las señales que esperan los defensores. Una herramienta de integridad de archivos que genere hash del contenido de los archivos aún puede detectarlo. Las herramientas que se basan en metadatos, registros de auditoría basados en rutas o advertencias del núcleo no lo detectarán.

Deben cumplirse las tres condiciones siguientes:

1. El sistema ejecuta un núcleo de Linux vulnerable basado en la versión 4.11 o posterior, sin la corrección.
2. El sistema de archivos XFS en cuestión se creó con compatibilidad con reflink.
3. En ese mismo sistema de archivos se encuentran un objetivo protegido de solo lectura y un directorio en el que el atacante puede escribir.

Comprueba el sistema de archivos raíz y todos los volúmenes XFS montados en los que se pueda ejecutar código local no fiable, ya que un volumen de datos independiente puede quedar expuesto incluso aunque el volumen raíz no lo esté:

xfs_info / | grep reflink=

Si la salida contiene «reflink=1», significa que se cumple el requisito previo del sistema de archivos.

Qualys incluye a RHEL, CentOS Stream, Oracle Linux, Rocky Linux, AlmaLinux y CloudLinux 8, 9 y 10 entre las distribuciones empresariales más afectadas, junto con Fedora Server 31 y versiones posteriores, Amazon Linux 2023 y las AMI de Amazon Linux 2 publicadas a partir de diciembre de 2022.

Debian, Ubuntu, SLES, openSUSE y Fedora Workstation no utilizan XFS para el directorio raíz de forma predeterminada, y solo quedan expuestos si un administrador elige XFS con reflink activado. Los sistemas de archivos de RHEL 7 son anteriores a la compatibilidad de XFS con reflink y quedan fuera del ámbito de exposición predeterminado que se describe aquí.

No intentes llegar a una «situación segura» basándote en razonamientos. La carrera solo se activa cuando el bloque de destino comienza sin compartir, lo que lleva a suponer que un archivo que ya has copiado mediante «reflink» es inmune; sin embargo, un usuario sin privilegios puede restablecer ese estado, y es poco probable que los binarios con setuid-root se hayan copiado mediante «reflink» en primer lugar. Esa restricción aparente no ofrece un límite de seguridad fiable.

Nuestro equipo del núcleo ha reproducido la vulnerabilidad en las siguientes versiones y ha comprobado que las versiones correspondientes de los fabricantes incluyen la corrección:

Se trata de versiones puntuales específicas. La cobertura varía según el flujo, por lo que debes consultar el aviso correspondiente a tu versión concreta, en lugar de basarte en una versión similar.

Las configuraciones predeterminadas de Enterprise Linux facilitan la explotación

El requisito de que sea el mismo sistema de archivos parece restrictivo. En una instalación empresarial típica, no lo es, ya que la estructura predeterminada de XFS de raíz única agrupa todo esto en un solo volumen:

• Archivos ejecutables de propiedad de root en /usr/bin
• Datos de autenticación en /etc
• El directorio /tmp, en el que todos pueden escribir
• Directorios de inicio de los usuarios en /home

Esto proporciona a un usuario sin privilegios tanto destinos de gran valor a los que puede leer como espacio temporal en el que puede escribir, todo ello en el mismo sistema de archivos habilitado para reflink. Imagina los entornos en los que esto puede darse: un servidor de compilación compartido, un ejecutor de CI que ejecuta lo último que se ha enviado en una solicitud de fusión, un nodo multitenant en el que cargas de trabajo en contenedores o restringidas pueden acceder a rutas adecuadas en el mismo sistema de archivos XFS del servidor, o un equipo de desarrollador que ejecuta dependencias no fiables. En cada uno de estos casos, una cuenta normal es todo lo que necesita el exploit.

Se trata de una escalada de privilegios a nivel local del host, no de una ejecución remota de código ni de una fuga del invitado al hipervisor. Un atacante tiene que conseguir primero la ejecución de código local. Una vez que lo consigue, RefluXFS convierte ese punto de acceso en privilegios de root del host.

Por qué las medidas habituales de refuerzo de la seguridad en Linux no lo impiden

RefluXFS no es un exploit convencional que provoque la corrupción de la memoria del núcleo. Aprovecha las operaciones normales del sistema de archivos para desviar una operación de escritura hacia un bloque físico incorrecto, razón por la cual muchas defensas habituales no lo detectan:

• SELinux: Qualys ha reproducido la explotación con SELinux en modo «Enforcing».
• KASLR, SMEP y SMAP: protegen contra las vías de corrupción de la memoria, no contra la asignación de bloques del sistema de archivos, por lo que nunca se activan.
• Bloqueo del núcleo: no impone ninguna restricción a las operaciones habituales de reflink o de E/S directa para los usuarios sin privilegios.
• Contenedores y espacios de nombres: no bloquean automáticamente el acceso a la ruta del sistema de archivos vulnerable.
• Seccomp: los perfiles típicos permiten las operaciones habituales con archivos que utiliza el ataque.
• Al reiniciar sin actualizar: el archivo dañado sigue ahí, y al arrancar con el mismo núcleo vulnerable, la vulnerabilidad sigue presente.

No se necesitan capacidades especiales. Ni CAP_SYS_ADMIN, ni espacio de nombres con privilegios, ni hardware inusual, ni configuración personalizada del núcleo. Los requisitos previos relacionados con XFS, reflink y el mismo sistema de archivos siguen siendo válidos, pero ya están presentes de forma predeterminada en muchas instalaciones de Linux empresarial afectadas.

No existe ninguna solución alternativa de configuración que esté exenta de riesgos, pero Red Hat ha publicado una medida de mitigación temporal en tiempo de ejecución.

La opción «reflink» se selecciona al crear el sistema de archivos XFS. No existe ninguna opción de montaje ni ningún parámetro sysctl que permita convertir un sistema de archivos existente con «reflink=1» en uno sin «reflink», y volver a crear el sistema de archivos no es una solución de emergencia para entornos de producción. Eliminar los bits setuid de «su», «sudo» o «pkexec» interrumpe el funcionamiento normal y no constituye una solución específica.

El equipo de seguridad de productos de Red Hat ha publicado una medida de mitigación provisional para SystemTap que intercepta el punto de entrada de reflink en XFS y obliga a las operaciones de reflink a devolver un error de «operación no compatible». Es posible aplicar un enfoque similar con kprobes. Esto bloquea la ruta de reflink vulnerable, pero modifica el comportamiento del sistema de archivos y puede afectar a las aplicaciones que dependen de la clonación mediante reflink, por lo que se recomienda probarlo primero en un entorno de pruebas. Considérelo como una protección temporal para los sistemas que no puedan actualizarse de inmediato, no como un sustituto de un núcleo corregido.

La solución definitiva es un núcleo corregido, tanto si se reinicia el sistema como si no.

La instalación de un paquete del núcleo no modifica el núcleo que ya se está ejecutando en memoria. En el caso de una actualización convencional del proveedor: instala la actualización del núcleo correspondiente exactamente a tu versión, reinicia el sistema y comprueba que se ha iniciado con ese núcleo.

uname -r

Para las ramas específicas mencionadas anteriormente, las versiones fijas sometidas a prueba son 4.18.0-553.144.1.el8_10, 5.14.0-687.26.1.el9_8 y 6.12.0-211.34.1.el10_2. Comprueba cuál es tu kernel actual consultando el aviso correspondiente a tu distribución, rama y arquitectura concretas.

Hay dos errores que hay que evitar. No te guíes por el paquete más reciente del disco, sino por el núcleo que se está ejecutando. Y no des por sentado que todos los núcleos compilados después del 16 de julio incluyen la corrección, ya que los números de versión de las distribuciones no se corresponden con las versiones originales y algunas ramas la incorporaron antes. Compruébalo consultando el aviso del proveedor correspondiente a la rama específica. Dado que algunos proveedores lanzaron la corrección antes de que se hiciera público el CVE, es posible que los escáneres basados en CVE no ofrezcan una visión completa del historial de parches.

Parcheo sin reinicio

RefluXFS se adapta bien a la aplicación de parches sin necesidad de reiniciar el sistema. La corrección consiste en un cambio específico en la forma en que el código de XFS actualiza la asignación de bloques tras completar un ciclo del bloqueo de inodos, sin que se produzca ningún cambio en el formato del disco ni ninguna sustitución de las estructuras de datos del núcleo en todo el sistema.

El aviso público de Qualys recomienda instalar un núcleo corregido y reiniciar el sistema, y señala acertadamente que reflink no se puede desactivar en un sistema de archivos activo ya existente.

KernelCare sigue un enfoque diferente para la corrección: aplica la corrección del código XFS subyacente directamente al núcleo en ejecución, en lugar de intentar desactivar reflink o modificar la configuración del sistema de archivos.

A continuación, la ruta CoW vulnerable vuelve a muestrear la correspondencia de la bifurcación de datos tras el ciclo de bloqueo, sin necesidad de una ventana de mantenimiento ni de reiniciar la carga de trabajo. Se trata de un error exclusivo del núcleo, sin ningún componente de biblioteca del espacio de usuario que haya que investigar.

Los usuarios de KernelCare suelen tener configurados los parches de manera que todas las nuevas correcciones se apliquen automáticamente, en segundo plano, a intervalos específicos —por ejemplo, cada 4 horas—. No obstante, los usuarios también pueden aplicar cualquier parche del canal de producción una vez que se haya publicado:

kcarectl --update

Comprueba la correspondencia con el CVE en lugar de fiarte de la fecha de compilación, ya que un kernel compilado después de mediados de julio no incluye automáticamente esta corrección:

kcarectl --patch-info | grep 'CVE-2026-64600'

Si un parche sigue en fase de promoción a través del canal de pruebas de tu familia de kernels, comprueba su disponibilidad antes de confiar en la cobertura sin necesidad de reiniciar y, mientras tanto, reinicia el sistema con el kernel del proveedor ya corregido.

Consigue KernelCare hoy mismo →

Detección y análisis de incidentes

No existe un único indicador fiable de RefluXFS, por lo que debes considerar cada uno de los siguientes como una pista, no como una prueba.

La comprobación más rigurosa en el disco aprovecha el propio punto ciego del fallo: el contenido ha cambiado, pero los metadatos no. La verificación de paquetes calcula el hash del contenido de los archivos, por lo que se activa incluso cuando el mtime y el modo parecen correctos. Empieza por verificar los paquetes que sean sensibles desde el punto de vista de la seguridad:

rpm -V shadow-utils sudo util-linux polkit

Un 5 en la cadena de resultados de verificación indica una discrepancia en el resumen. En un binario con setuid-root o en un archivo de configuración principal, sin la marca de tiempo T ni el cambio de modo M correspondientes, esto es coherente con el tipo de modificación que RefluXFS puede dejar. En los sistemas de la familia Debian, la orden «debsums -c» cumple la misma función. La verificación de paquetes no abarcará todos los archivos de configuración mutables importantes, por lo que conviene complementarla con copias de seguridad fiables, registros de gestión de la configuración y hash de archivos que se sabe que son correctos.

Céntrate en los objetivos de alto valor:

/etc/passwd   /etc/shadow   /etc/sudoers
/usr/bin/su   /usr/bin/sudo   /usr/bin/passwd   /usr/bin/pkexec

A continuación, busca las señales de comportamiento: cuentas privilegiadas nuevas o sin contraseña inesperadas, campos de la cuenta root modificados, programas setuid cuyo contenido ya no coincide con el paquete instalado, claves SSH inexplicables, aumentos de privilegios sin que haya un evento correspondiente de «sudo», inicio de sesión o autenticación, picos de E/S directa simultánea procedentes de un proceso sin privilegios y clonación mediante enlaces reflink de archivos protegidos en ubicaciones en las que el usuario tiene permiso de escritura.

Una marca de tiempo normal o un modo de permisos sin cambios no implican que el archivo esté limpio. Si se ha ejecutado código no fiable en un host vulnerable durante el periodo de exposición, considéralo como un posible riesgo para la integridad y analiza con mayor detenimiento las cuentas, la configuración de autenticación y los servicios, en lugar de interpretar un registro del núcleo sin incidencias como prueba de seguridad.

Por qué es importante RefluXFS

Es fácil subestimar RefluXFS porque hay tres aspectos que, a primera vista, parecen limitantes. Es local, no remoto. Requiere XFS. Requiere reflinks.

En Linux empresarial, esos tres elementos describen el entorno predeterminado, y las máquinas que se ajustan a ellos son precisamente aquellas en las que se ejecuta el código de terceros: inquilinos, procesos de compilación, contenedores, complementos y servicios comprometidos.

Además, la vulnerabilidad traspasa la barrera de seguridad de una forma inusual. No hay ninguna escritura directa en el archivo protegido, no hay que eludir SELinux ni se utiliza ninguna carga útil en la memoria del núcleo. El núcleo simplemente escribe datos válidos, controlados por el atacante, en el bloque de disco equivocado, y el resultado es persistente, con privilegios de root y silencioso.

Aquí también hay una lección sobre los procesos, y es la que hay que aplicar a tu cola de triaje. Para muchos administradores, la primera señal sobre la que se pudo actuar públicamente pudo haber sido una actualización habitual del kernel de un proveedor, lanzada antes de la divulgación del CVE y descrita como una corrección de corrupción de datos en XFS. Ese es el patrón silencioso de «primero la corrección, luego el CVE», y una cola que se basara únicamente en las erratas de seguridad habría clasificado una LPE local con privilegios de root como mantenimiento rutinario. Estad atentos a los avisos de corrección de errores del kernel, no solo a los marcados como de seguridad.

En el caso de los sistemas en los que se aplican parches de forma convencional, instala la actualización del proveedor y comprueba que el equipo realmente arranca con ella. En el caso de las flotas en las que los reinicios de emergencia suponen un riesgo operativo, un parche sin reinicio de KernelCare corrige la vulnerabilidad del sistema de archivos XFS en el núcleo en ejecución sin desconectar los nodos ni interrumpir las cargas de trabajo.

Consigue KernelCare hoy mismo →

Cronología

Referencias

• Qualys, «RefluXFS: una vulnerabilidad en el núcleo de Linux que permite la escalada de privilegios locales a root en XFS (CVE-2026-64600)», 22 de julio de 2026: https://blog.qualys.com/vulnerabilities-threat-research/2026/07/22/refluxfs-a-linux-kernel-local-privilege-escalation-to-root-in-xfs-cve-2026-64600
• Informe técnico de Qualys, «RefluXFS: Escalada de privilegios locales mediante una carrera de acceso a E/S directa con reflink en XFS», oss-security 2026/q3, 22 de julio de 2026
• Medida de mitigación provisional de Red Hat Product Security para SystemTap, lista de correo de oss-security (hilo sobre CVE-2026-64600)
• Página de Red Hat sobre CVE, CVE-2026-64600: https://access.redhat.com/security/cve/cve-2026-64600
• Erratas de seguridad de Red Hat RHSA-2026:39179 y RHSA-2026:39180 (RHEL 8), RHSA-2026:39494 (RHEL 10)
• Corrección en el código fuente: «xfs: remuestrear la asignación de la rama de datos tras un ciclo de ILOCK» (commit 2f4acd0), incorporada el 16 de julio de 2026
• Commit 3c68d44a2b49, que introduce un error: «xfs: asignar bloques COW de E/S directa en iomap_begin» (Linux 4.11)
• The Hacker News, «Una vulnerabilidad de nueve años en RefluXFS para Linux otorga privilegios de root a los usuarios locales en las instalaciones predeterminadas de RHEL»: https://thehackernews.com/2026/07/nine-year-old-refluxfs-linux-flaw-gives.html
• Avisos de seguridad aplicables a las distribuciones AlmaLinux, Rocky Linux, Oracle Linux, Fedora y Amazon Linux