“Dirty Frag” CVE-2026-43284, CVE-2026-43500

“Dirty Frag” es una cadena de vulnerabilidades de escalada local de privilegios en el kernel de Linux, divulgada el 7 de mayo de 2026, y asociada a los CVE-2026-43284, CVE-2026-43500 y, en algunas fuentes, también a CVE-2026-46300 (“Fragnesia”).

Qué es

A alto nivel, Dirty Frag afecta a subsistemas de red del kernel relacionados con IPsec/ESP y RxRPC, y permite a un usuario local llegar a root al abusar de escrituras sobre memoria respaldada por page cache.

Impacto

El impacto práctico es serio porque un atacante que ya tenga acceso local a la máquina puede elevar privilegios rápidamente; en sistemas con contenedores o cargas de terceros, también puede facilitar escenarios de escape del contenedor.

Qué la hace peligrosa

La técnica es especialmente preocupante porque no depende de una ventana de carrera clásica: se describe como un fallo determinista, con alta fiabilidad, parecido en espíritu a Dirty Pipe y Copy Fail.

Alcance probable

Las fuentes consultadas indican que afecta a múltiples distribuciones y que el código vulnerable lleva bastante tiempo presente en el árbol del kernel, con un rango temporal aproximado que empieza en 2017 para una de las variantes y en 2023 para otra.

Mitigación

Mientras llegan los parches, la mitigación temporal más citada es deshabilitar los módulos esp4, esp6 y rxrpc, aunque eso puede romper IPsec o entornos que dependan de AFS/RxRPC.

Recomendación práctica

Si administras Linux, prioriza: restringir acceso local, revisar qué capacidades das a contenedores, mantener SELinux/AppArmor activos y aplicar actualizaciones del kernel en cuanto tu distribución publique correcciones.

El vector de ataque principal es local: el atacante necesita ya tener ejecución en el sistema, aunque sea con privilegios bajos, y desde ahí puede escalar a root abusando de cómo el kernel maneja ciertos fragmentos de memoria en rutas de red/cifrado.

Vector de ataque

Dirty Frag no es un RCE remoto “por Internet”; el punto de entrada típico es una cuenta local comprometida, un servicio ya explotado, un contenedor con acceso limitado o una carga de trabajo de terceros dentro del host.

Las descripciones técnicas apuntan a dos rutas principales: una ligada a ESP/IPsec, donde el fallo está en el manejo de fragmentos skb compartidos mediante MSG_SPLICE_PAGES, y otra ligada a RxRPC/AFS, donde hay una descompartición incorrecta de paquetes DATA o RESPONSE con fragmentos paginados.

Lo relevante para un atacante es que la explotación se describe como determinista y de alta fiabilidad, no como una condición de carrera frágil; por eso puede repetirse sin que el kernel necesariamente colapse.

Medidas de mitigación

La mitigación más sólida es aplicar los parches del kernel publicados por tu proveedor, porque las mitigaciones de otras vulnerabilidades relacionadas, como Copy Fail, no cubren Dirty Frag.

Mientras no haya parche disponible, se recomienda deshabilitar temporalmente los módulos esp4, esp6 y rxrpc si no se usan, bloqueándolos en modprobe y descargándolos del sistema.

INCIBE también publica un comando de mitigación temporal que crea una regla para impedir la carga de esos módulos y limpia cachés del sistema; el propio aviso insiste en que es una medida provisional, no un reemplazo del parche.

Prioridad operativa

Debes tratar como más expuestos los sistemas con acceso local para usuarios, SSH, CI/CD, hosting compartido, Kubernetes o contenedores con privilegios elevados.

Si administras servidores, conviene revisar también el estado de confinement del host, limitar contenedores privilegiados y mantener la menor superficie posible para ejecución local no confiable.

Ejemplo práctico

En un servidor que no use IPsec ni AFS/RxRPC, la mitigación temporal típica es bloquear esos módulos hasta poder actualizar el kernel; si sí los necesitas, la prioridad pasa a ser parchear cuanto antes y planificar reinicio.