ssh-keysign-pwn (CVE-2026-46333): filtración local de información en Linux, claves host SSH y riesgo para /etc/shadow

ssh-keysign-pwn se refiere a un conjunto de rutas de explotación alrededor de un fallo lógico en __ptrace_may_access() del Linux kernel, asignado como CVE-2026-46333. No es una vulnerabilidad remota sin autenticación y no entrega directamente una shell de root, pero el riesgo sigue siendo alto: un usuario local con pocos privilegios podría leer archivos sensibles de root que no debería poder acceder, como claves privadas de host SSH o /etc/shadow.

Para equipos de operaciones, la prioridad no es reproducir un PoC. La prioridad es identificar máquinas afectadas, actualizar el kernel, reiniciar para entrar en el kernel corregido y rotar claves de host SSH o restablecer contraseñas cuando sea necesario.

Conclusión rápida

Esta vulnerabilidad merece una prioridad alta por cuatro motivos:

La puede activar un usuario local de bajo privilegio, sin root.
Ya existe PoC público, lo que reduce mucho la barrera de explotación.
Los objetivos potenciales no son archivos comunes, sino claves privadas de host SSH y /etc/shadow.
La corrección requiere parche de kernel y reinicio; instalar paquetes sin reiniciar no basta.

Si tus servidores tienen múltiples usuarios, shell local, hosting compartido, CI runners, hosts de contenedores, aulas, bastiones o cualquier usuario local que no sea completamente confiable, conviene tratarlo primero.

Qué es la vulnerabilidad

Qualys publicó detalles en oss-security el 15 de mayo de 2026. Antes había informado a security@kernel.org de un problema lógico en __ptrace_may_access() del Linux kernel, y la corrección upstream ya había sido integrada por Linus. Después apareció código de explotación público, por lo que Qualys compartió la información en oss-security.

El equipo CVE del Linux kernel asignó luego CVE-2026-46333. La página de NVD muestra kernel.org como fuente, y la descripción corresponde al commit del kernel ptrace: slightly saner 'get_dumpable()' logic.

En términos simples, el fallo está en la ruta de salida de procesos. Cuando algunos procesos privilegiados están terminando, la lógica del kernel relacionada con las comprobaciones de acceso de ptrace puede omitir una comprobación dumpable que debería aplicarse, porque la tarea objetivo ya no tiene mm. Un atacante puede competir en una ventana muy estrecha y obtener descriptores de archivo que el proceso privilegiado en salida todavía mantiene abiertos.

Por eso se lo llama ssh-keysign-pwn: una de las rutas públicas de explotación gira alrededor de ssh-keysign para leer SSH host private keys.

Por qué puede exponer claves host SSH y /etc/shadow

En esencia, es una filtración local de información. Abusa de una ventana durante la salida de un programa privilegiado en la que el descriptor de memoria ya se separó, pero los descriptores de archivo aún no se cerraron.

El aviso de AlmaLinux explica el riesgo con claridad: si un programa privilegiado abrió archivos sensibles antes de bajar privilegios, y el atacante logra capturar el descriptor de archivo correspondiente durante la ventana de salida, esos archivos sensibles podrían leerse.

Dos objetivos frecuentes en la discusión pública son:

ssh-keysign: puede involucrar claves privadas de host SSH como /etc/ssh/ssh_host_*_key.
chage: puede involucrar /etc/shadow.

Si se filtran claves privadas de host SSH, un atacante podría suplantar el host y debilitar la confianza en la identidad SSH del servidor. Si se filtra /etc/shadow, un atacante puede crackear hashes de contraseña offline y ampliar el compromiso después.

Por eso debe tratarse como un problema de alta prioridad aunque no sea una vulnerabilidad de “root shell directo”.

Cómo evaluar la exposición

Desde la perspectiva upstream, es una vulnerabilidad del Linux kernel. Los registros de NVD muestran que el problema entró en el dataset de NVD el 15 de mayo de 2026, y en ese momento todavía no tenía puntuación CVSS.

El estado por distribución debe verificarse en los avisos de cada proveedor:

AlmaLinux 8, 9 y 10 publicaron orientación y el 16 de mayo de 2026 actualizaron el aviso para indicar que los patched kernels ya estaban en repositorios de producción.
Debian Security Tracker lista estados vulnerable/fixed y versiones corregidas para bullseye, bookworm, trixie, sid y otras ramas.
Para otras distribuciones, revisa las páginas oficiales de seguridad o repositorios de Ubuntu, Red Hat, SUSE, Arch, Alpine, etc.

No evalúes la seguridad solo por la versión upstream del kernel. Las distribuciones hacen backport de correcciones, por lo que un mismo número de versión aparente puede representar estados de parche diferentes.

Qué máquinas priorizar

Orden recomendado de prioridad:

Servidores multiusuario y hosts compartidos.
Bastiones, máquinas de enseñanza, equipos de desarrollo y otros sistemas con cuentas shell normales.
CI runners, máquinas de build y nodos de plataformas de hosting.
Hosts de contenedores y virtualización, sobre todo donde conviven workloads no completamente confiables.
Máquinas con servicios públicos. La vulnerabilidad requiere acceso local, pero el riesgo se combina si un bug web, RCE, contraseña débil u otro camino da al atacante un punto de apoyo de bajo privilegio.

Los escritorios de un solo usuario tienen un riesgo relativamente menor, pero aun así deberían actualizarse con el sistema. La ejecución local de código con bajo privilegio no es rara en escritorios, a través de navegadores, herramientas de desarrollo, scripts y software de terceros.

Recomendaciones de corrección

La solución preferida es instalar el kernel corregido que entrega la distribución y reiniciar.

Los comandos cambian por distribución, pero el principio es el mismo:

Actualizar metadatos de paquetes.
Instalar el paquete kernel que contiene la corrección de CVE-2026-46333.
Reiniciar en el kernel nuevo.
Usar uname -r y el aviso de seguridad de la distribución para verificar que el kernel en ejecución está corregido.

El aviso de AlmaLinux indica que los kernels corregidos están disponibles en repositorios de producción y que los usuarios pueden ejecutar el dnf upgrade habitual y reiniciar. Debian tracker también lista fixed versions para varias ramas.

Importante: si solo instalas un paquete kernel nuevo pero no reinicias, el kernel antiguo vulnerable sigue ejecutándose.

Mitigación temporal: endurecer ptrace_scope

Si no puedes reiniciar de inmediato, endurece primero ptrace_scope de Yama.

Qualys confirmó en una respuesta posterior en oss-security que configurar /proc/sys/kernel/yama/ptrace_scope en 2 (admin-only attach) o 3 (no attach) bloquea las rutas públicas de explotación que conocen. También aclararon que, en teoría, podrían existir otros métodos de explotación, por lo que esto es una mitigación, no una corrección.

Configuración temporal:

1

sudo sysctl -w kernel.yama.ptrace_scope=3

Configuración persistente:

1

echo 'kernel.yama.ptrace_scope = 3' | sudo tee /etc/sysctl.d/99-ssh-keysign-pwn.conf

ptrace_scope=3 desactiva ptrace attach y puede afectar flujos de depuración como gdb y strace -p. Si necesitas depuración en producción, evalúa 2. En cualquier caso, agenda la actualización de kernel y el reinicio cuanto antes.

¿Hay que rotar claves host SSH?

Conviene adoptar una postura conservadora si la máquina tenía alguna de estas condiciones durante la ventana de exposición:

Usuarios locales no confiables.
Hosting compartido o entornos multi-tenant de contenedores/CI.
Vulnerabilidades web, contraseñas débiles, scripts de cadena de suministro u otros caminos que puedan dar un punto de apoyo local.
Procesos locales sospechosos, comportamiento de depuración anómalo o archivos PoC públicos en logs.
Exposición prolongada antes de aplicar la corrección.

Una respuesta conservadora incluye:

Rotar SSH host keys después de parchear y reiniciar.
Actualizar sistemas de gestión de huellas de hosts conocidos.
Notificar a automatizaciones que dependan de esa huella de host.
Revisar alertas de conexión SSH para no confundir cambios legítimos de huella con ataques de intermediario, ni ignorar riesgos reales.

Si sospechas que /etc/shadow se filtró, evalúa también restablecimiento de contraseñas, prohibición de contraseñas débiles y revisión de hashes antiguos que puedan crackearse offline.

Qué monitorear

La ventana de explotación es breve, así que los logs tradicionales podrían no capturarlo todo. Aun así, revisa:

Archivos como ssh-keysign-pwn, chage_pwn o artefactos PoC similares en directorios de usuarios normales.
Actividad de compilación sospechosa, como programas C desconocidos compilados en poco tiempo.
Señales de acceso anómalo a /etc/ssh/ssh_host_*_key o /etc/shadow.
Actividad inusual de pidfd_getfd, ptrace o depuradores.
Reportes externos de cambios inesperados en la huella del host SSH.

Estas señales no prueban que hubo explotación, y su ausencia tampoco prueba que no la hubo. Las prioridades reales siguen siendo parchear, reiniciar, rotar credenciales y aislar el riesgo.

Malentendidos comunes

Primero: no es una vulnerabilidad remota de OpenSSH. El nombre incluye ssh-keysign, pero la causa raíz está en la lógica de comprobación de acceso ptrace del Linux kernel, no en el flujo de autenticación remota de sshd.

Segundo: no tener usuarios locales no elimina todo el riesgo. La vulnerabilidad sí requiere ejecución local, pero muchas cadenas reales obtienen primero un punto de apoyo local de bajo privilegio mediante servicios web, CI, scripts, contraseñas débiles o escapes de contenedor.

Tercero: configurar ptrace_scope no basta. Es una mitigación temporal, no una corrección raíz. La actualización del kernel y el reinicio siguen siendo necesarios.

Cuarto: no haber obtenido root no significa que no haya incidente. La filtración de claves privadas de host SSH o /etc/shadow puede bastar para movimiento lateral, suplantación de host y cracking offline.

Checklist de respuesta

Orden recomendado:

Inventariar hosts Linux afectados, especialmente entornos multiusuario y compartidos.
Revisar avisos oficiales de seguridad de la distribución e identificar la fixed kernel version.
Instalar el kernel corregido y reiniciar.
En máquinas que no puedan reiniciarse de inmediato, configurar kernel.yama.ptrace_scope=2 o 3.
Verificar la versión del kernel en ejecución después de la corrección.
Rotar SSH host keys en máquinas de alto riesgo.
Si se sospecha exposición de /etc/shadow, evaluar restablecimiento de contraseñas y auditoría de cuentas.
Buscar PoCs públicos, compilaciones anómalas y comportamiento local de depuración sospechoso.

Resumen

ssh-keysign-pwn (CVE-2026-46333) es una vulnerabilidad local de filtración de información causada por lógica relacionada con __ptrace_may_access() en el Linux kernel. No permite entrar remotamente de forma directa y no concede una shell de root directa, pero puede permitir que un usuario local de bajo privilegio lea archivos sensibles de alto valor. Eso la vuelve especialmente importante en entornos multiusuario, hosting compartido, CI y hosts de contenedores.

La corrección fiable es actualizar al kernel corregido de la distribución y reiniciar. ptrace_scope=2/3 puede servir como mitigación temporal, pero no reemplaza el parche. En hosts críticos expuestos durante la ventana de riesgo, también conviene evaluar rotación de claves host SSH y riesgo de contraseñas.

Referencias: