Un fallo en el kernel que permite obtener privilegios de administrador
Una nueva vulnerabilidad de seguridad identificada como CVE-2026-46331, conocida informalmente como pedit COW, ha puesto de nuevo el foco sobre uno de los mecanismos internos más sensibles del núcleo de Linux: la gestión de memoria mediante Copy-on-Write (COW).
El fallo afecta al subsistema de control de tráfico (Traffic Control o tc) y permite que un usuario sin privilegios pueda obtener acceso como root en determinados sistemas, siempre que se cumplan unas condiciones concretas de configuración. La publicación de un exploit funcional apenas un día después de la asignación del CVE ha acelerado la necesidad de aplicar las actualizaciones de seguridad disponibles.
¿En qué consiste la vulnerabilidad?
El origen del problema se encuentra en act_pedit, un módulo del kernel encargado de modificar determinados campos de las cabeceras de los paquetes de red durante su procesamiento.
Durante estas operaciones, el kernel debería trabajar sobre una copia privada de la memoria utilizando el conocido mecanismo Copy-on-Write, evitando modificar páginas compartidas.
Sin embargo, debido a un error en la validación de los desplazamientos de escritura, determinadas operaciones pueden terminar escribiendo fuera del área prevista y alterar directamente páginas compartidas de la caché del sistema.
En otras palabras, el kernel acaba modificando la copia en memoria de un fichero ejecutable sin alterar el archivo almacenado en disco.
Un ataque especialmente difícil de detectar
Uno de los aspectos más preocupantes de esta vulnerabilidad es precisamente su capacidad para actuar únicamente sobre la imagen del ejecutable cargada en memoria.
El exploit público modifica temporalmente la copia cacheada del binario /bin/su, inserta un pequeño código malicioso y ejecuta ese binario ya alterado para obtener privilegios de administrador.
Como el fichero original nunca llega a modificarse, los mecanismos tradicionales de verificación de integridad continúan indicando que el sistema permanece intacto, mientras el atacante ya dispone de una sesión con privilegios elevados.
Este comportamiento recuerda a vulnerabilidades anteriores como Dirty Pipe, Dirty COW o Dirty PageCache, todas ellas basadas en la corrupción de páginas compartidas del kernel.
Sistemas afectados
La explotación requiere que concurran dos circunstancias:
- Que el módulo act_pedit pueda cargarse en el sistema.
- Que estén habilitados los User Namespaces para usuarios sin privilegios, ya que proporcionan la capacidad CAP_NET_ADMIN necesaria para activar el fallo.
Las pruebas públicas realizadas por el autor del exploit han confirmado la escalada de privilegios en:
- Red Hat Enterprise Linux 10.
- Debian 13 (Trixie).
Por su parte:
- Ubuntu 24.04 puede resultar vulnerable dependiendo de la configuración de AppArmor.
- Ubuntu 26.04 restringe este vector de ataque por defecto mediante políticas más estrictas de AppArmor, aunque el fallo del kernel continúa existiendo.
- Red Hat también considera afectados RHEL 8, RHEL 9 y RHEL 10.
Recomendaciones para administradores
La medida prioritaria consiste en instalar las actualizaciones del kernel publicadas por cada fabricante y reiniciar los sistemas afectados.
En aquellos entornos donde la actualización inmediata no sea posible, pueden adoptarse algunas medidas temporales para reducir el riesgo:
- Deshabilitar la carga del módulo act_pedit si no se utiliza en la infraestructura.
- Desactivar los User Namespaces para usuarios sin privilegios, teniendo presente que esta medida puede afectar al funcionamiento de contenedores sin privilegios (rootless containers), determinados entornos CI/CD y algunos mecanismos de aislamiento utilizados por navegadores modernos.
También es importante recordar que eliminar la caché del sistema únicamente elimina la copia modificada del ejecutable, pero no revierte un posible compromiso del servidor si el atacante ya ha conseguido una sesión con privilegios de administrador.
Una vulnerabilidad que vuelve a evidenciar la importancia de la gestión de parches
Más allá del propio fallo técnico, este caso pone de manifiesto otro aspecto relevante de la seguridad en Linux: muchas correcciones llegan inicialmente como aparentes mejoras de estabilidad o integridad de datos antes de ser catalogadas oficialmente como vulnerabilidades de seguridad.
En este caso, la corrección estuvo disponible durante varias semanas en las listas públicas de desarrollo del kernel antes de que se asignara el identificador CVE y apareciera un exploit completamente funcional.
Para las organizaciones que gestionan infraestructuras Linux, este incidente refuerza la importancia de mantener una política de actualización continua, especialmente en servidores compartidos, nodos de virtualización, plataformas Kubernetes, entornos de desarrollo y sistemas multiusuario, donde la presencia de usuarios locales incrementa notablemente el riesgo de explotación.
