CVE-2026-43284

Introducción

Bajo el nombre Dirty Frag, y con identificador CVE-2026-43284, se engloban dos vulnerabilidades nuevas que permiten escalar privilegios en Linux. Son muy similares a las anteriores vulnerabilidades Dirty Pipe y Copy Fail y, al igual que ellas, requiere de un usuario local para poder ejecutarse o de ejecución de comandos en un contenedor para poder acceder al host. Sin embargo, el código vulnerable es otro, y por lo tanto las mitigaciones y los parches de las anteriores vulnerabilidades no tienen efecto en ésta.

En el caso actual de Dirty Frag, se basa en código vulnerable en dos módulos distintos: (fuente; https://github.com/tangjie1/dirtyfrag-check)

Estas dos vulnerabilidades son complementarias; en casi todas las distribuiciones linux posteriores al 2017, si no funciona un método funciona el otro.

Gravedad y prioridad

La vulnerabilidad está confirmada, los datos técnicos han sido publicados y el exploit es fácil de conseguir. Por ello la prioridad asignada es:

• Para sistemas afectados; prioridad "ACTÚA AHORA" (menos de 24h).
  • Si no es posible aplicar el parche o la mitigación durante el día de hoy, recomendamos encarecidamente apagar los equipos afectados.
• Para sistemas no afectados; prioridad "Actúa este mes" (instalar los parches de seguridad proporcionados por el fabricante cuando estén disponibles en el plazo de un mes).

Sistemas afectados

Por su función

Todas las distribuciones Linux desde el kernel 4.14 (del año 2017) están potencialmente afectadas, pero para ejecutar el exploit es necesario disponer de acceso local. Por ello, sólo los sistemas que cumplen estas funciones tienen un riesgo práctico:

• Con usuarios locales no confiables:
  • Aulas
  • Servidores de prácticas
  • VDI y polilabs
• Contenedores:
  • Docker, Kubernetes.
    • Que publiquen shells o permitan ejecutar procesos a los usuarios.
  • Pipelines CD/CI. Runners de gitlab.

NOTA CONTENEDORES; los host y los contenedores tienen un aislamiento lógico de procesos, no físico; comparten el mismo kernel y una parte de la memoria ram (page cache). Por ello, un bug o un exploit a nivel de kernel puede escapar del aislamiento del contenedor y escalar a root en el host. Este método no es aplicable a servidores de máquinas virtuales, ya que no es posible escribir en la ram del host a partir de un exploit del sistema virtual.

Distribuciones afectadas

El investigador de seguridad que ha descubierto la vulnerabilidad ha confirmado que las siguientes distribuciones son vulnerables:

• Ubuntu 24.04.4: 6.17.0-23-generic
• RHEL 10.1: 6.12.0-124.49.1.el10_1.x86_64
• openSUSE Tumbleweed: 7.0.2-1-default
• CentOS Stream 10: 6.12.0-224.el10.x86_64
• AlmaLinux 10: 6.12.0-124.52.3.el10_1.x86_64
• Fedora 44: 6.19.14-300.fc44.x86_64
• ...

También se ha cofnirmado que Debian 13 está afectado. fuente; You can add Debian 13 / Trixie to your list btw · Issue #7 · V4bel/dirtyfrag

Debian

Debian ya dispone de parches que resuelven la vulnerabilidad (a fecha de 9/05/2026)

Fuente; https://security-tracker.debian.org/tracker/CVE-2026-43284

Posibles soluciones y migitaciones

Mitigación e IPSEC

Antes de aplicar ninguna medida de mitigación, compruebe que el sistema no es un terminador de túneles IPSEC con estos comandos:

ip xfrm policy list 2>/dev/null | head
ss -tunap | grep -i rxrpc

Si la salida no está vacía, la mitigación afectará a la funcionalidad de túnel IPSEC.

Mitigación

Esta medida de mitigación deshabilita los módulos que contienen el código vulnerable.

sudo sh -c "printf 'install esp4 /bin/false\ninstall esp6 /bin/false\ninstall rxrpc /bin/false\n' > /etc/modprobe.d/dirtyfrag.conf; rmmod esp4 esp6 rxrpc 2>/dev/null; true"

Después de mitigar, eliminese la page-cache:

sudo echo 3 > /proc/sys/vm/drop_caches

Fuente: Dirty Frag [CVE Pending]: Mitigation and Kernel Update on CloudLinux

https://tuxcare.com/blog/dirty-frag-explained-linux-root-exploit-mitigation-patching-guide 

Cómo aplicar el parche o la mitigación en VDI y Polilabs

El proceso para aplicar cambios de forma definitiva en sistemas VDI consiste en estos pasos:

1. Encender la máquina máster y aplicarle los cambios (parcheo/mitigación).
2. Crear imagen de la máster.
3. Volver a generar máquinas de usuario, clones de la última máster.

Se recuerda que parchear las máquinas de usuario no tiene efecto, ya que esos cambios se perderán cuando se vuelvan a regenerar de la master.

No es necesario reiniciar, pero hay que borrar la page-caché

Si la mitigación se aplica DESPUÉS de que alguien haya ejecutado el exploit, éste sigue funcionando en memoria, y puede seguir siendo utilizado.

En la vulnerabilidad anterior (copy fail) indicábamos que era necesario reiniciar para eliminar la elevación de privilegios. En este caso no es necesario reiniciar, basta con un comando para borrar la page-caché.

sudo echo 3 > /proc/sys/vm/drop_caches

Historial de la vulnerabilidad

La información de la vulnerabilidad ha sido publicada inicialmente por un tercero antes de tiempo, rompiendo el embargo y sin margen para incluir los parches en las distribuciones.

• 026-04-30: Submitted detailed information about the esp vulnerability and a weaponized exploit that achieves root privileges on several major distributions to security@kernel.org.
• 2026-04-30: Submitted the patch for the esp vulnerability to the netdev mailing list. Information about this issue was published publicly.
• 2026-04-30 (+9h): Kuan-Ting Chen submitted a vulnerability report for the esp vulnerability with a reproducer to security@kernel.org.
• 2026-05-04: Kuan-Ting Chen submitted the shared-frag approach patch to the netdev mailing list.
• 2026-05-07: The patch was merged into the netdev tree.
• 2026-05-07: Submitted detailed information about the vulnerability and the exploit to the linux-distros mailing list. The embargo was set to 5 days, with an agreement that if a third party publishes the exploit on the internet during the embargo period, the Dirty Frag exploit would be published publicly.
• 2026-05-07: Detailed information and the exploit for this vulnerability were published publicly by an unrelated third party, breaking the embargo.
• 2026-05-07: After obtaining agreement from distribution maintainers to fully disclose Dirty Frag, the entire Dirty Frag document was published.

Fuente; https://github.com/V4bel/dirtyfrag/blob/master/assets/write-up.md#disclosure-timeline

Otras fuentes de interés:

GitHub - V4bel/dirtyfrag · GitHub 

Linux Kernel Dirty Frag LPE Exploit Enables Root Access Across Major Distributions