Un usuario local sin privilegios no debería poder leer las claves privadas del host SSH ni /etc/shadow. CVE-2026-46333, bautizado ssh-keysign-pwn, abre justamente esa puerta a través de una carrera en el subsistema ptrace del kernel Linux. Qualys lo reportó al equipo de seguridad del kernel el 11 de mayo de 2026, el parche se integró el 14 de mayo y NVD publicó la entrada el 15 con un CVSS de 7.1 (vector AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:N).
Dónde está el fallo
El problema vive en __ptrace_may_access() y la lógica de get_dumpable(). Cuando un proceso termina, el kernel separa primero su descriptor de memoria (mm) y solo después cierra su tabla de descriptores de fichero. Entre esos dos momentos hay una ventana muy corta en la que mm ya es NULL, y la comprobación de acceso de ptrace se salta su salvaguarda de “dumpable” precisamente porque no encuentra mapa de memoria asociado.
Ahí entra pidfd_getfd(2), la interfaz introducida en Linux 5.6 que permite clonar un descriptor abierto de otro proceso. Durante esa ventana, un proceso sin privilegios puede llamar a pidfd_getfd(2) contra un binario SUID que esté saliendo y copiarse sus descriptores ya abiertos. El blanco son binarios SUID que abren ficheros propiedad de root en su ruta normal de ejecución: sobre todo ssh-keysign (que lee las claves privadas del host SSH) y chage (que lee la base de datos de contraseñas en sombra).
El bug no es nuevo. Está en el código de mainline desde noviembre de 2016 y arranca en una propuesta de parche de Jann Horn que nunca llegó a fusionarse. Qualys desarrolló cuatro exploits funcionales: contra chage, ssh-keysign, pkexec y accounts-daemon.
A quién afecta y con qué gravedad
Cualquier sistema con un kernel que incluya pidfd_getfd() (Linux 5.6 y posteriores) y la lógica vulnerable de ptrace. La lista de distribuciones con aviso publicado incluye Debian 13, Ubuntu 24.04 y 26.04, Fedora 43 y 44, SUSE, AlmaLinux y CloudLinux.
No es ejecución remota ni da root directo, y por eso se queda en CVSS 7.1 en vez de subir más. Pero leer las claves de host SSH y los hashes de /etc/shadow es grave de verdad: con la clave privada del host puedes suplantar el servidor en ataques man-in-the-middle, y con los hashes de contraseñas puedes intentar romperlas sin prisa fuera de la máquina. En entornos multiusuario, hosting compartido o servidores con cuentas de poca confianza, el riesgo es directo.
Cómo mitigarlo
Lo correcto es actualizar el kernel a la versión parcheada que publique tu distribución y reiniciar. Los avisos de Debian, Ubuntu, Fedora, SUSE, AlmaLinux y CloudLinux ya estaban disponibles a mediados de mayo de 2026.
Si tienes que esperar al parche, hay una mitigación interina sólida: sube kernel.yama.ptrace_scope a 2, lo que limita el attach de ptrace solo a administradores. Eso bloquea los exploits públicos, porque su ruta vía pidfd_getfd(2) pasa por __ptrace_may_access().
sysctl -w kernel.yama.ptrace_scope=2Para hacerlo persistente, añade kernel.yama.ptrace_scope = 2 a /etc/sysctl.d/. Ten en cuenta que esto puede afectar a depuradores y herramientas que necesiten ptrace entre procesos del mismo usuario, así que pruébalo antes en producción.
Este es otro recordatorio de que la escalada local sigue siendo terreno fértil en el kernel. Si quieres ver casos parecidos, échale un vistazo a Copy Fail (CVE-2026-31431), otra escalada a root en el módulo crypto del kernel. Y para seguir las versiones del kernel y sus parches, tienes la ficha de Linux kernel.