Dirty Frag (CVE-2026-43284): el fallo del núcleo de Linux que convierte el acceso de lectura en acceso de root

Un archivo de solo lectura debería seguir siendo de solo lectura. La vulnerabilidad «Dirty Frag» (CVE-2026-43284, CVE-2026-43500 y CVE-2026-46300) consigue que el núcleo de Linux modifique su copia almacenada en caché de todos modos.

Esta vulnerabilidad permite que un programa que se ejecute prácticamente sin privilegios escriba en archivos que, en teoría, solo debería poder leer, modificando la copia que el núcleo mantiene en memoria. A partir de ahí, puede reescribir algún elemento en el que el sistema confía y otorgarse a sí mismo acceso de root. En entornos de contenedores, el mismo truco que permite acceder al núcleo del host también puede acceder al núcleo del nodo compartido por todas las cargas de trabajo.

El fallo de seguridad lleva años presente en el código de redes del núcleo, por lo que afecta a la mayoría de las versiones del núcleo compatibles y a casi todas las distribuciones principales. Linux ha corregido el fallo y todas las distribuciones lo han adaptado a sus versiones anteriores, por lo que la corrección aparecerá con un número de versión diferente en cada una de ellas.

Resumen de «Dirty Frag»

Red Hat agrupa tres CVE bajo el nombre de «Dirty Frag». Se encuentran en diferentes partes del código de redes del núcleo, y uno de ellos es una variante posterior que no se incluyó en la primera ronda de parches. A continuación se muestra una comparación entre ellos.

El subsistema te indica si esto te afecta. Si no utilizas VPN IPsec ni AFS, es una indicación rápida de hasta qué punto debes prestarle atención. El módulo es lo que debes comprobar (lsmod | grep -E 'esp4|esp6|rxrpc') para ver qué hay cargado.

Linux mantiene en la memoria los datos de los archivos a los que se ha accedido recientemente, para no tener que leerlos del disco cada vez. Esa copia en memoria se denomina caché de páginas. Ciertas funciones del núcleo, como splice() pasar esos datos almacenados en caché al código de red sin copiarlos, sino entregando un puntero a la ubicación donde ya se encuentran los datos. Esto ahorra trabajo, siempre y cuando cada paso posterior sepa que la memoria es compartida y no escriba en ella.

El error apareció en dos partes distintas del código de redes del núcleo. Una era ESP, que gestiona el tráfico VPN cifrado. La otra era RxRPC, un protocolo más antiguo utilizado principalmente por el sistema de archivos AFS. Ni la ruta ESP ni la de RxRPC comprueban si la memoria es compartida antes de escribir en ella.

Esto permitía a un atacante hacerse con un archivo de solo lectura que, si se manipulaba, podía otorgarle privilegios, algo así como /usr/bin/su, e introduce su contenido en la ruta de red para que el proceso de descifrado defectuoso acabe escribiendo en la memoria de ese archivo. La escritura acaba en la caché de páginas, que es la copia del archivo que el sistema proporciona a cualquier proceso que lo lea. El archivo del disco nunca cambia, pero la versión en memoria ahora muestra lo que el atacante ha hecho que muestre. Al ejecutar «su», se lee la copia manipulada y se concede al atacante acceso de root, aunque en realidad solo tuviera permiso para leer ese archivo.

Fragnesia, registrada como CVE-2026-46300, es la variante más reciente. La corrección de «Dirty Frag» hizo que el núcleo se basara en un marcador que indica: «este fragmento es compartido; haz una copia segura antes de modificarlo». Sin embargo, un antiguo error de 2013 en el código que fusiona fragmentos de paquetes elimina silenciosamente ese marcador. Permaneció inofensivo durante trece años porque nada dependía de él. Por desgracia, la corrección de «Dirty Frag» sí dependía de él, lo que convirtió un error latente en una nueva vía de acceso a privilegios de root. 

¿Por qué es importante el «Dirty Frag» en el caso de los contenedores?

Todos los contenedores comparten un mismo núcleo con el host, por lo que un contenedor comprometido puede acceder al código vulnerable del núcleo si sus permisos lo permiten (llamadas al sistema, espacios de nombres o configuración de la política de seguridad). Los investigadores ya han publicado exploits de prueba de concepto que funcionan para Kubernetes, y Ubuntu detalla el riesgo que supone un contenedor escape. Si el contenedor puede acceder al núcleo, el riesgo es el acceso como usuario root en todo el nodo.

Puedes neutralizar parte del ataque ejecutando las cargas de trabajo sin privilegios de root, activando el perfil seccomp «RuntimeDefault», aplicando políticas de pod restringidas y limitando los espacios de nombres de usuario sin privilegios. Pero nada de eso soluciona la vulnerabilidad en sí. Solo la actualización del kernel del proveedor lo consigue.

¿Cómo se puede saber si un servidor está expuesto?

Empieza por el host que está realmente en ejecución, no por el Dockerfile. Hay tres comandos que te pueden ayudar.

Ejecuta uname -r Para averiguar qué versión del núcleo estás utilizando, compárala con la versión corregida que figura en el aviso de seguridad de tu distribución. No la compares con el número del desarrollador original. El patrón vulnerable se remonta a núcleos de alrededor de 2017, y las distribuciones empresariales y LTS, como RHEL, Ubuntu y Debian, retroportan la corrección a la versión más antigua del núcleo que ya estás utilizando, por lo que un núcleo parcheado puede seguir indicando una versión de hace años. Un host RHEL 8 totalmente parcheado sigue indicando la versión 4.18, y esa versión 4.18 ya incluye la corrección. Compruébalo con la versión del paquete corregido de tu proveedor.

lsmod | grep -E 'esp4|esp6|rxrpc' Indica si se ha cargado la ruta de código vulnerable. Un resultado vacío no significa que no haya ningún riesgo, ya que estos módulos se cargan bajo demanda. Y el hecho de que se haya cargado no implica automáticamente que sea peligroso. esp4, esp6 y rxrpc son módulos comunes que resultan totalmente seguros en un núcleo parcheado. Esto te permite conocer tu superficie de ataque y determinar si merece la pena aplicar la medida de mitigación de la lista negra.

sysctl user.max_user_namespaces muestra el grado de accesibilidad de la ruta ESP. Un valor superior a cero significa que los usuarios sin privilegios pueden crear espacios de nombres, que es la vía habitual de acceso a la ruta ESP. El valor cero cierra esa puerta, pero solo para ESP. La ruta RxRPC no necesita espacios de nombres, por lo que no ofrece una protección total.

Comprueba el estado de tu proveedor. Red Hat afirma que CVE-2026-43500 no afecta a sus productos, mientras que CVE-2026-43284 y CVE-2026-46300 sí afectan a los núcleos de Red Hat Enterprise Linux para los que ofrece soporte y a cualquier sistema basado en ellos. Ubuntu publica la versión exacta del paquete corregido para cada línea de núcleo para la que ofrece soporte.

¿Qué aspectos debes supervisar?

El código de prueba de concepto ya es público. Microsoft ha informado de una actividad limitada en el mundo real en la que un atacante amplía sus privilegios utilizando su, aunque hay que tener en cuenta que podría tratarse de «Dirty Frag» o de su predecesor, «Copy Fail», ya que es difícil distinguirlos solo a partir de los registros de procesos.

La forma más realista de detectar esto es mediante las herramientas de auditoría y EDR que ya utilizas. El marco de auditoría de Linux puede registrar la ejecución de procesos y las transiciones setuid, que es donde aparecería la secuencia reveladora: la descarga y ejecución de un binario desconocido, seguida inmediatamente por su. Presta atención a si se cargan esp4, esp6 o rxrpc en el momento en que se produzcan otras actividades sospechosas, especialmente en un host que no tenga motivos para utilizar IPsec o AFS, y a si se ejecutan archivos ELF recién descargados. 

Si sospechas que se está produciendo una explotación, realiza las comprobaciones de integridad desde un entorno de confianza, en lugar de desde el propio host, que podría estar comprometido. Y recuerda que bloquear los módulos del núcleo no revierte los cambios que un atacante ya haya realizado en la caché de páginas.

El lugar que ocupa el aikido

La mayoría de los escaneos se detienen en la imagen o en el repositorio. Dirty Frag se encuentra un nivel más abajo, en el núcleo desde el que realmente arranca el nodo.

Aikido Security escaneo de máquinas virtuales lee lo que está realmente instalado en el host en ejecución a partir de una instantánea en la nube, por lo que un paquete del núcleo vulnerable aparece como un hallazgo del host. Como además vincula los hosts con las cargas de trabajo y las cuentas que se ejecutan en ellos, puedes ver el alcance del impacto si se compromete un nodo.

En el caso de los servidores en la nube conectados a Aikido, escaneo de máquinas virtuales muestra aquellos que contienen el paquete del kernel vulnerable e indica qué cargas de trabajo se ejecutan en ellos. La solución es la misma: aplicar el parche al kernel del nodo y comprobar la versión cargada tras el reinicio.

{{cta}}

Preguntas frecuentes