La vulnerabilidad CVE-2026-46333, conocida como ssh-keysign-pwn o ptrace exit-race, no es una simple alerta más del kernel de Linux. El fallo permite que un usuario local sin privilegios lea archivos propiedad de root en determinadas condiciones, incluidos secretos tan sensibles como las claves privadas del host SSH o la base de datos /etc/shadow, donde se almacenan los hashes de contraseñas del sistema.
No estamos ante una vulnerabilidad remota de OpenSSH ni ante un fallo que se corrija cambiando una opción de sshd_config. El problema está en el kernel, concretamente en la lógica de control de acceso de ptrace. La explotación requiere capacidad de ejecutar código localmente, pero en servidores multiusuario, plataformas de hosting, entornos CI/CD, bastiones, máquinas de desarrollo compartidas o sistemas donde un atacante ya haya conseguido una cuenta limitada, el impacto puede ser muy serio.
La entrada de NVD para CVE-2026-46333 describe el cambio como una corrección en la lógica de get_dumpable(): la “dumpability” tiene sentido para tareas con una imagen de memoria asociada, pero ptrace_may_access() la estaba usando también en casos donde el proceso ya no tenía mm. Debian, AlmaLinux y CloudLinux ya han publicado información específica sobre el fallo y parches o mitigaciones para distintas ramas del kernel.
Un fallo local que puede terminar en compromiso real
La mecánica del fallo es sutil. Durante la salida de un proceso privilegiado, hay una ventana en la que el contexto de memoria de la tarea ya se ha separado, pero sus descriptores de archivo siguen abiertos. En ese intervalo, un proceso local sin privilegios puede aprovechar pidfd_getfd(2) para copiar descriptores abiertos por un binario privilegiado que se está cerrando. CloudLinux señala como objetivos principales a binarios SUID como ssh-keysign, que puede abrir claves privadas del host SSH, y chage, relacionado con /etc/shadow.
La diferencia con una escalada clásica a root es importante, pero no tranquilizadora. El atacante no obtiene necesariamente una shell root en el primer paso. Lo que obtiene puede ser igual de peligroso: acceso de lectura a secretos que normalmente solo debería poder consultar root. Con una clave privada del host SSH, un adversario puede intentar suplantar un servidor hasta que se roten las claves. Con /etc/shadow, puede llevarse los hashes y atacarlos fuera de línea.
En servidores personales de un solo usuario el riesgo depende mucho del contexto. En servidores compartidos el panorama cambia. Una cuenta web comprometida, un usuario de pruebas olvidado, un runner de CI vulnerable o una cuenta de cliente en un entorno de hosting pueden convertirse en punto de partida para extraer secretos del host.
Conviene evitar una lectura demasiado mecánica de “si es local, es menos grave”. Muchas intrusiones empiezan precisamente con un acceso local limitado. A partir de ahí, lo que marca la diferencia es si el sistema impide al atacante salir de su caja o le permite tocar credenciales que abren más puertas.
Qué sistemas están afectados y cómo comprobarlos
La vulnerabilidad afecta a kernels con la lógica vulnerable. El exploit público depende de pidfd_getfd(2), una interfaz disponible en kernels modernos, por lo que hay diferencias entre “tener el bug” y “ser explotable con el PoC actual”. CloudLinux indica que CloudLinux 8 LTS, 9 y 10 son afectados por la prueba de concepto pública, mientras que CloudLinux 7 no está afectado y CloudLinux 7h/8 presentan la lógica vulnerable, pero no son explotables por el PoC actual al no exponer esa syscall en su línea 4.18.
En AlmaLinux, las ramas 9 y 10 son vulnerables con los exploits públicos, mientras que AlmaLinux 8 incluye la lógica defectuosa, aunque el PoC actual no funcione directamente sobre su kernel 4.18. La distribución publicó versiones corregidas para AlmaLinux 8, 9 y 10, y posteriormente indicó que los kernels parcheados ya estaban llegando a repositorios de producción.
En Debian, el Security Tracker ya recoge versiones corregidas para bullseye, bookworm, trixie y unstable. Por ejemplo, lista 5.10.251-5 para bullseye security, 6.1.172-1 para bookworm security y 6.12.88-1 para trixie security.
La comprobación básica empieza por saber qué kernel se está ejecutando:
uname -rEn distribuciones donde haya dudas sobre el exploit público, también puede comprobarse si pidfd_getfd está expuesto al espacio de usuario:
grep -w __NR_pidfd_getfd /usr/include/asm-generic/unistd.h 2>/dev/null || \
grep -w __NR_pidfd_getfd /usr/include/x86_64-linux-gnu/asm/unistd_64.h 2>/dev/nullLenguaje del código: JavaScript (javascript)Que esa llamada no aparezca no significa automáticamente que el kernel no contenga la lógica vulnerable. Solo indica que el exploit público conocido puede no funcionar tal cual. En seguridad del kernel, esa diferencia importa: si la rama está afectada, debe parchearse.
Mitigaciones recomendadas para administradores Linux
La mitigación correcta es actualizar el kernel del proveedor y reiniciar. Todo lo demás debe tratarse como medida temporal o defensa en profundidad. Si el sistema usa live patching y el proveedor confirma cobertura para CVE-2026-46333, puede evitarse el reinicio inmediato, pero aun así conviene verificar explícitamente que el parche está aplicado.
En sistemas basados en RHEL, AlmaLinux, Rocky Linux, Oracle Linux o CloudLinux, el camino habitual será actualizar paquetes del kernel y reiniciar:
sudo dnf clean metadata
sudo dnf upgrade 'kernel*'
sudo rebootLenguaje del código: JavaScript (javascript)Después del reinicio:
uname -r
rpm -q kernelEn Debian y Ubuntu:
sudo apt update
sudo apt full-upgrade
sudo rebootDespués:
uname -r
dpkg -l 'linux-image*' | grep '^ii'Lenguaje del código: JavaScript (javascript)En Arch Linux y derivadas:
sudo pacman -Syu
sudo rebootLa segunda vía es el live patching. CloudLinux menciona KernelCare como alternativa para aplicar correcciones de seguridad del kernel sin reiniciar, siempre que el livepatch concreto esté disponible para la versión afectada. En entornos con KernelCare, la verificación debería hacerse con:
sudo kcarectl --update
sudo kcarectl --patch-info | grep CVE-2026-46333La tercera opción, especialmente en CloudLinux, es usar el sysctl específico kernel.user_ptrace=0 mientras se aplica el parche definitivo. CloudLinux lo recomienda como medida rápida porque bloquea a nivel de host que usuarios sin privilegios usen ptrace; además, es reversible.
sudo sysctl -w kernel.user_ptrace=0Para hacerlo persistente:
echo 'kernel.user_ptrace = 0' | sudo tee /etc/sysctl.d/99-ptracenull.conf
sudo sysctl --systemLenguaje del código: PHP (php)Tiene coste operativo: usuarios sin privilegios no podrán usar herramientas como gdb -p, strace -p o ciertos flujos de perf sobre sus propios procesos. En servidores de producción suele ser asumible; en estaciones de desarrollo o runners de CI puede romper usos legítimos.
En distribuciones sin kernel.user_ptrace, una mitigación temporal pasa por endurecer Yama. LWN recoge que kernel.yama.ptrace_scope=1 no basta para este caso, y que 2 o 3 bloquean los PoC conocidos en distintos escenarios, aunque hay matices con espacios de nombres de usuario no privilegiados. La opción más estricta es 3, pero desactiva el adjuntado con ptrace incluso para root y puede afectar mucho a depuración y observabilidad.
Temporalmente:
sudo sysctl -w kernel.yama.ptrace_scope=3Persistente:
echo 'kernel.yama.ptrace_scope = 3' | sudo tee /etc/sysctl.d/99-ssh-keysign-pwn.conf
sudo sysctl --systemLenguaje del código: PHP (php)Una alternativa menos agresiva, pero que debe evaluarse bien, es combinar:
sudo sysctl -w kernel.yama.ptrace_scope=2
sudo sysctl -w kernel.unprivileged_userns_clone=0Y persistirlo:
cat <<'EOF' | sudo tee /etc/sysctl.d/99-ssh-keysign-pwn.conf
kernel.yama.ptrace_scope = 2
kernel.unprivileged_userns_clone = 0
EOF
sudo sysctl --systemLenguaje del código: JavaScript (javascript)Esta combinación mantiene más margen para depuración por root, pero puede romper aplicaciones que dependan de user namespaces sin privilegios, como algunos flujos de contenedores rootless, sandboxing o herramientas de desarrollo. No debe aplicarse a ciegas en plataformas de contenedores sin probar antes.
La cuarta medida es retirar el bit SUID de los binarios usados por los exploits públicos conocidos, principalmente ssh-keysign y chage. CloudLinux lo plantea como defensa en profundidad si no puede aplicarse la mitigación por sysctl y si CageFS no está disponible.
sudo chmod u-s /usr/libexec/openssh/ssh-keysign 2>/dev/null
sudo chmod u-s /usr/lib/openssh/ssh-keysign 2>/dev/null
sudo chmod u-s /usr/bin/chageLenguaje del código: JavaScript (javascript)Verificación:
ls -l /usr/libexec/openssh/ssh-keysign /usr/lib/openssh/ssh-keysign /usr/bin/chage 2>/dev/nullLenguaje del código: JavaScript (javascript)La línea no debería mostrar -rws, sino -rwx. Hay que tener en cuenta los efectos: ssh-keysign se usa para HostbasedAuthentication, poco común en muchos servidores, pero no inexistente; chage sin SUID limita a usuarios no root a la hora de consultar o modificar información de caducidad de sus propias contraseñas. Además, esta medida solo cubre los objetivos conocidos del PoC, no todos los posibles binarios SUID que podrían abrir archivos sensibles durante su salida.
En CloudLinux, CageFS aporta otra capa. Según CloudLinux, los tenants enjaulados quedan protegidos porque los binarios SUID objetivo no están presentes dentro de la vista del sistema de archivos de la jaula. Pero esto no cubre cuentas no enjauladas ni usuarios administrativos del host, así que no sustituye al parche del kernel ni a una mitigación de host.
También merece la pena revisar la superficie local. Si un servidor permite acceso shell a usuarios no confiables, ejecuta trabajos CI de terceros, aloja múltiples clientes o contiene cuentas antiguas, este es un buen momento para eliminar accesos que no sean imprescindibles. La explotación requiere presencia local, por lo que cada cuenta innecesaria aumenta el riesgo.
Después del parche: claves, contraseñas y evidencias
Actualizar el kernel cierra la vía conocida, pero no repara automáticamente secretos que hayan podido filtrarse antes. Si el servidor estuvo expuesto a usuarios locales no confiables, conviene rotar las claves del host SSH y revisar credenciales locales.
En Debian y Ubuntu, una regeneración controlada puede hacerse con:
sudo rm /etc/ssh/ssh_host_*
sudo dpkg-reconfigure openssh-server
sudo systemctl restart sshEn sistemas de la familia RHEL, el comando puede variar por distribución, pero una opción habitual es:
sudo rm /etc/ssh/ssh_host_*
sudo sshd-keygen
sudo systemctl restart sshdDespués hay que distribuir las nuevas huellas a usuarios, herramientas de monitorización, bastiones, automatizaciones y sistemas de despliegue:
ssh-keygen -lf /etc/ssh/ssh_host_ed25519_key.pubSi hay sospecha de lectura de /etc/shadow, la respuesta debería incluir cambio de contraseñas de cuentas locales con privilegios, revisión de políticas PAM, bloqueo de cuentas obsoletas y comprobación de accesos recientes. No basta con mirar si alguien hizo sudo: la extracción de hashes puede no dejar señales obvias más allá de procesos anómalos, actividad de ptrace, ejecución repetida de binarios SUID o uso extraño de pidfd_getfd.
Para equipos de monitorización, tiene sentido vigilar procesos que ejecuten repetidamente ssh-keysign o chage, intentos de ptrace, fallos o patrones inusuales alrededor de binarios SUID, y actividad local desde cuentas que normalmente no deberían lanzar herramientas de depuración. En entornos con eBPF, auditd o EDR para Linux, la prioridad es detectar comportamiento anómalo, no buscar una firma única.
La recomendación más prudente para servidores compartidos es tratar CVE-2026-46333 con la misma urgencia que una escalada local de privilegios, aunque técnicamente sea una divulgación de información. En Linux, leer secretos de root puede ser suficiente para llegar al mismo resultado por otro camino.
Preguntas frecuentes
¿ssh-keysign-pwn es una vulnerabilidad de OpenSSH?
No. El fallo está en el kernel de Linux, en la lógica de acceso de ptrace. ssh-keysign aparece porque es uno de los binarios SUID usados por el exploit público para intentar leer claves privadas del host SSH.
¿La explotación requiere acceso local?
Sí. El atacante necesita ejecutar código en la máquina vulnerable. Por eso son especialmente sensibles los servidores multiusuario, entornos de hosting, runners de CI/CD, máquinas de desarrollo compartidas y sistemas donde ya exista una cuenta comprometida.
¿Basta con cambiar una opción de SSH?
No. La corrección real es actualizar el kernel. Rotar claves SSH puede ser necesario después, pero no elimina la vulnerabilidad del sistema.
¿Qué mitigación temporal es más recomendable?
Depende de la distribución. En CloudLinux, kernel.user_ptrace=0 es la mitigación rápida recomendada por el fabricante. En otras distribuciones puede usarse Yama con kernel.yama.ptrace_scope=3, o ptrace_scope=2 combinado con la desactivación de user namespaces sin privilegios, asumiendo los posibles efectos sobre depuración y contenedores.
