DirtyClone (CVE-2026-43503): el fallo del kernel Linux que da root sin dejar rastro en disco

Otra de la familia «Dirty»

Si llevas unos años administrando servidores Linux, el apellido «Dirty» te suena a problema serio. DirtyCOW en 2016, DirtyPipe en 2022… y ahora, en apenas seis semanas, nos han caído tres primos nuevos: Dirty Frag, Fragnesia y, el que ha hecho más ruido, DirtyClone.

El 25 de junio, los investigadores de JFrog publicaron el primer exploit funcional de CVE-2026-43503, al que bautizaron DirtyClone. Y el 1 de julio Canonical sacó su aviso confirmando que todos los Ubuntu soportados estaban afectados y que los kernels parcheados ya están disponibles. Lo escribimos con el parche recién aplicado en las máquinas que gestionamos, porque este merece que le prestes atención esta misma semana.

En una frase

Cuando el kernel copia internamente un paquete de red, dos funciones auxiliares (__pskb_copy_fclone() y skb_shift()) se olvidan de propagar un flag —SKBFL_SHARED_FRAG— que marca que la memoria de ese paquete está compartida con un fichero del disco (la page cache).

Ese flag perdido es toda la vulnerabilidad. Un usuario local puede colocar en memoria las páginas de un binario privilegiado —por ejemplo /usr/bin/su—, «enchufarlas» dentro de un paquete, forzar al kernel a clonarlo y hacerlo pasar por un túnel IPsec que él controla. La operación criptográfica in-place de descifrado sobrescribe esas páginas, y con ellas la copia en memoria del binario. Cambia las comprobaciones de login por bytes elegidos por el atacante.

Resultado: root. Sin exploit remoto, sin escalar por la vía clásica, con un binario que ya estaba en el sistema.

Lo que lo hace especialmente incómodo: no deja rastro

Aquí está el detalle que diferencia a DirtyClone de una escalada de privilegios normal: el fichero del disco no cambia ni un solo byte.

La modificación vive únicamente en la copia en memoria que el kernel mantiene en la page cache. Las consecuencias son las que le quitan el sueño a cualquiera que haga análisis forense:

• Las herramientas de integridad de ficheros (AIDE, Tripwire, debsums) no ven nada: el hash del binario en disco es el correcto.
• No hay logs del cambio.
• Un simple reinicio restaura el binario original, porque la copia envenenada solo estaba en RAM.

Es decir: un atacante puede conseguir root, hacer lo que necesite y, cuando la máquina se reinicie, la evidencia principal se evapora sola. Para un servidor multi-tenant o de hosting compartido, esto es exactamente el tipo de fallo que no quieres tener abierto ni un día de más.

A quién afecta

• Distribuciones afectadas: todas las de la familia. Canonical confirma todos los Ubuntu soportados; el fallo está en el stack de red del kernel, así que Debian, RHEL/AlmaLinux/Rocky y compañía comparten la raíz.
• Quién lo puede explotar: cualquier usuario local que tenga —o pueda conseguir— la capacidad CAP_NET_ADMIN. Y ahí está la trampa: en muchos sistemas esa capacidad se obtiene de forma trivial a través de los espacios de nombres de usuario sin privilegios (unprivileged user namespaces), que vienen activados por defecto.
• Contenedores: además de la escalada local, el fallo puede facilitar escapes de contenedor si los privilegios de red no están bien acotados.
• CVSS 8.8 (alta). Hay exploit público desde el 25 de junio. No es teórico.

Traducido al día a día: si tienes usuarios SSH no confiables, hosting compartido, contenedores, o cualquier cuenta local que no controles al 100 %, estás en el perímetro de riesgo.

Versiones parcheadas en Ubuntu

Estos son los kernels a partir de los cuales el fallo está cerrado, según el aviso oficial de Canonical:

Los kernels de nube (AWS, Azure, GCP, Oracle, KVM, Raspberry Pi…) tienen sus propias versiones parcheadas equivalentes. Comprueba la tuya con uname -r y contrástala con el aviso de tu distribución: no te fíes solo del número, mira la fecha del paquete.

Qué tienes que hacer hoy

Sin rodeos. Esto es lo que aplicamos estos días en las máquinas de clientes.

1. Actualizar el kernel y reiniciar

Es la única solución definitiva. Y sí, requiere reinicio.

# Debian / Ubuntu
sudo apt update && sudo apt upgrade
sudo reboot

# RHEL / AlmaLinux / Rocky
sudo dnf update kernel
sudo reboot

Antes de reiniciar, confirma que el grub apunta al kernel nuevo (dpkg --list | grep linux-image en Debian/Ubuntu, grubby --default-kernel en familia RHEL). Reiniciar por error al kernel viejo a las tres de la madrugada es un clásico que conviene evitar.

Si tienes unattended-upgrades activo, el parche se aplica solo en las próximas 24 horas —pero el reinicio no. Programa la ventana de reinicio tú.

2. Mitigación temporal mientras no puedes reiniciar

Si la máquina no admite parada inmediata, corta la vía por la que se explota el fallo: desactiva los espacios de nombres de usuario sin privilegios, que es de donde el atacante saca el CAP_NET_ADMIN que necesita.

En Ubuntu 24.04 o superior (con AppArmor):

sudo sysctl -w kernel.apparmor_restrict_unprivileged_userns=1

En versiones anteriores:

sudo sysctl -w kernel.unprivileged_userns_clone=0

Para hacerlo persistente entre reinicios:

echo "kernel.apparmor_restrict_unprivileged_userns=1" | sudo tee /etc/sysctl.d/99-cve-2026-43503.conf

Ojo: esto cierra el camino de explotación más cómodo, no elimina el fallo, y puede romper contenedores o herramientas que dependan de user namespaces sin privilegios (algunos flujos de Docker/Podman rootless, bwrap, etc.). Pruébalo antes en un entorno de staging. No te libra de actualizar.

3. Si tienes Ubuntu Pro, mira Livepatch

Para servidores en los que la ventana de reinicio está lejos, comprueba si el parche está disponible por Livepatch (pro status / canonical-livepatch status). Aplica el fix en caliente sin reiniciar, como puente hasta la próxima parada planificada.

4. Auditar, con la salvedad importante

Revisa lo de siempre —/var/log/auth.log, journalctl, auditd con llamadas a ptrace/creación de namespaces— pero asume que este fallo apenas deja huella. Como el binario en disco no cambia y un reinicio borra la copia envenenada, la ausencia de evidencias no demuestra que no te hayan tocado. Si el servidor tiene usuarios locales no confiables y llevaba días sin parchear, trátalo como potencialmente comprometido: rota credenciales y claves.

Lo que hemos hecho nosotros estos días

En Atenea Systems el orden fue el de siempre cuando sale una de estas:

1. Servidores con usuarios externos primero: hosting compartido, jails de clientes, máquinas con SFTP y cuentas locales de terceros.
2. Nodos con contenedores: por el riesgo añadido de escape.
3. VPS dedicados de un solo administrador: menor superficie local, van después.

Donde la ventana de reinicio aún no había llegado, dejamos activada la restricción de user namespaces como paliativo. A día de hoy todas las máquinas que gestionamos están en kernel parcheado o mitigadas a la espera de su reinicio programado.

Qué nos llevamos

DirtyClone no es un fallo remoto que cualquiera dispare desde internet: hace falta una cuenta local. Pero es precisamente el tipo de escalada que convierte «un usuario molesto» en «root en tu servidor», y encima sin dejar el rastro que normalmente te avisa de que algo va mal.

La receta, como cada vez que sale una de estas, se reduce a cinco gestos: mirar la versión del kernel, mirar la fecha del último reinicio, actualizar, reiniciar y verificar. Un plan de parcheo que funcione no es un lujo: es lo que separa el servidor que sobrevive a un mal miércoles del que no. Si el tuyo consiste en «cuando me acuerde», hablamos.

Referencias

• DirtyClone Linux kernel local privilege escalation vulnerability — fixes available (Canonical)
• Dissecting and Exploiting Linux LPE Variant: DirtyClone (CVE-2026-43503) — JFrog Security Research
• CVE-2026-43503 — Ubuntu Security
• 'DirtyClone' Linux Kernel Vulnerability Leads to Root Access — SecurityWeek