Vulnerability Fix on KnightLi Blog

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

Sun, 17 May 2026 09:29:03 +0800

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:

Dirty Frag CVE-2026-43284: riesgo de escalada local en Linux y guía de mitigación

Sat, 09 May 2026 07:25:55 +0800

Dirty Frag es un conjunto de vulnerabilidades de escalada local de privilegios en el kernel Linux, divulgadas en mayo de 2026 y con indicios de explotación activa. Microsoft la describe como un riesgo post-compromiso: después de que un atacante consigue ejecución con pocos privilegios, puede usar el fallo para escalar a root. Ubuntu también clasifica CVE-2026-43284 como High.

El peligro no está en un “compromiso remoto de un clic”. El peligro está en que, una vez dentro, el atacante puede ampliar el control rápidamente. Si consigue ejecución local mediante credenciales SSH débiles, una web shell, escape de contenedor, una cuenta de servicio con pocos privilegios o acceso remoto tras phishing, Dirty Frag puede permitir root y luego desactivar herramientas de seguridad, leer credenciales, manipular logs, moverse lateralmente o persistir.

Qué CVE están implicados

La información pública asocia Dirty Frag principalmente con dos identificadores:

CVE-2026-43284: relacionado con la ruta xfrm/ESP del kernel Linux. Las referencias de Microsoft a esp4 y esp6 pertenecen a esta zona de riesgo.
CVE-2026-43500: Microsoft indica que está relacionado con rxrpc, pero al 8 de mayo de 2026 el CVE aún no estaba publicado en NVD y el estado de parches seguía evolucionando.

Por eso no conviene mirar solo un CVE. Es más seguro revisar si esp4, esp6, rxrpc y funciones relacionadas con xfrm/IPsec están activas, son necesarias y ya tienen parche de la distribución.

Explicación técnica resumida

Según Microsoft y Ubuntu, CVE-2026-43284 afecta al manejo de red y fragmentos de memoria del kernel Linux, especialmente al tratamiento de fragmentos de página compartidos en la ruta ESP/IPsec.

En términos simples, páginas de datos pueden adjuntarse a buffers de red mediante mecanismos como splice. Si rutas posteriores del kernel tratan esos fragmentos como datos privados que se pueden modificar in-place, puede producirse descifrado o modificación in-place donde no debería. Un atacante puede manipular el comportamiento de page cache y acabar logrando escalada local.

Esto se parece a CopyFail (CVE-2026-31431): ambos giran en torno a page cache de Linux, rutas de datos del kernel y escalada local. Dirty Frag es peligroso porque introduce más rutas de ataque y puede ser más fiable que exploits LPE tradicionales dependientes de ventanas de carrera estrechas.

Entornos prioritarios

Dirty Frag es una vulnerabilidad local, así que el atacante ya debe poder ejecutar código en la máquina. Prioriza:

Servidores Linux con SSH expuesto.
Servidores web donde pueda escribirse una web shell.
Hosts multiusuario, bastiones, máquinas de desarrollo y runners CI/CD.
Hosts de contenedores, nodos Kubernetes y nodos OpenShift.
Sistemas que usen IPsec, VPN, xfrm o funcionalidad relacionada con RxRPC.
Servidores con Ubuntu, RHEL, CentOS Stream, AlmaLinux, Fedora, openSUSE y otras distribuciones comunes.

Si un servidor no tiene usuarios locales, contenedores ni rutas de aplicación expuestas, el riesgo es menor. Pero cualquier sistema donde un atacante pueda conseguir una shell de bajo privilegio debe tratar esto como un problema de kernel de alta prioridad.

Primero parchear

La corrección más segura es instalar la actualización de seguridad del kernel de tu distribución y reiniciar con el kernel nuevo.

La página de Ubuntu indica que CVE-2026-43284 se publicó el 8 de mayo de 2026 y se clasifica como High. Microsoft también dice que Linux Kernel Organization publicó correcciones para CVE-2026-43284 y recomienda aplicar parches cuanto antes.

Empieza revisando el sistema:

1
2

uname -a
cat /etc/os-release

Después actualiza el kernel según la distribución:

`1`	`sudo apt update && sudo apt full-upgrade`

`1`	`sudo dnf update`

Tras actualizar, confirma que el sistema arrancó con el kernel nuevo:

`1`	`uname -r`

Instalar paquetes de kernel sin reiniciar deja el kernel antiguo ejecutándose, así que la vulnerabilidad puede seguir presente.

Mitigación temporal: desactivar módulos relacionados

Si aún no hay parches, o producción no puede reiniciarse de inmediato, evalúa si puedes desactivar temporalmente los módulos relacionados. La mitigación de Ubuntu bloquea la carga de esp4, esp6 y rxrpc, y los descarga si ya están cargados.

Crear reglas modprobe:

1
2
3

echo "install esp4 /bin/false" | sudo tee /etc/modprobe.d/dirty-frag.conf
echo "install esp6 /bin/false" | sudo tee -a /etc/modprobe.d/dirty-frag.conf
echo "install rxrpc /bin/false" | sudo tee -a /etc/modprobe.d/dirty-frag.conf

Actualizar initramfs para evitar carga temprana:

`1`	`sudo update-initramfs -u -k all`

Descargar módulos ya cargados:

`1`	`sudo rmmod esp4 esp6 rxrpc 2>/dev/null`

Comprobar si siguen cargados:

`1`	`grep -qE '^(esp4\|esp6\|rxrpc) ' /proc/modules && echo "Affected modules are loaded" \|\| echo "Affected modules are NOT loaded"`

Si un módulo está en uso, puede no descargarse. En ese caso, la regla de bloqueo probablemente solo surtirá efecto tras reiniciar.

Evalúa impacto antes de desactivar

No pegues esos comandos a ciegas. esp4, esp6 y funciones xfrm/IPsec pueden usarse en VPN, túneles, redes cifradas, redes Kubernetes/contenedores o configuraciones empresariales. rxrpc también puede afectar cargas que dependan de ese protocolo.

Antes de ejecutar en producción, revisa al menos:

1
2
3

lsmod | grep -E '^(esp4|esp6|rxrpc|xfrm)'
ip xfrm state
ip xfrm policy

Si dependes de IPsec VPN o funciones relacionadas del kernel, desactivar módulos puede cortar conectividad. En ese caso, es mejor programar parcheo del kernel y ventana de mantenimiento que depender mucho tiempo del bloqueo de módulos.

No omitas comprobaciones post-compromiso

Microsoft recuerda que la mitigación no necesariamente revierte cambios ya introducidos por explotación exitosa. Si el atacante ya obtuvo root, puede haber dejado persistencia, modificado archivos, alterado logs o accedido a datos de sesión.

Comprueba al menos:

journalctl -k --since "24 hours ago" | grep -Ei "dirty|frag|exploit|segfault|xfrm|rxrpc|esp"
last -a
lastlog
sudo find /tmp /var/tmp /dev/shm -type f -mtime -3 -ls
sudo find / -perm -4000 -type f -mtime -7 -ls 2>/dev/null

También revisa:

Lanzamientos anómalos de su, sudo o procesos SUID/SGID.
Ejecutables ELF creados recientemente.
Archivos PHP, JSP o ASP sospechosos en directorios web.
Cambios en SSH authorized_keys.
Persistencia nueva en systemd services, cron o rc.local.
Contenedores privilegiados o montajes sospechosos en hosts de contenedores.

Si sospechas explotación, aísla el host, conserva evidencias, rota credenciales y luego limpia. No asumas que descargar módulos o limpiar cachés hace seguro el sistema.

Sobre drop_caches

Microsoft menciona que en algunos escenarios de verificación de integridad post-explotación puede evaluarse limpiar caché:

`1`	`echo 3 \| sudo tee /proc/sys/vm/drop_caches`

Esto no es una corrección de la vulnerabilidad ni un comando de limpieza de incidente. Limpiar cachés puede aumentar I/O de disco y afectar rendimiento en producción. Úsalo solo como paso auxiliar tras entender el impacto. La corrección real sigue siendo parchear, reiniciar, verificar integridad y revisar persistencia.

Orden recomendado de respuesta

Para producción, una secuencia razonable es:

Inventariar activos Linux y versiones de kernel.
Priorizar sistemas con SSH expuesto, workloads web, hosts de contenedores y acceso multiusuario.
Parchear y reiniciar cuanto antes los sistemas que puedan reiniciarse.
En sistemas que aún no puedan parchearse o reiniciarse, evaluar desactivar esp4, esp6 y rxrpc.
Aumentar monitorización de su, SUID/SGID, ELF sospechosos, web shells e indicadores de escape de contenedor.
Ejecutar comprobaciones post-compromiso y rotar credenciales en hosts sospechosos.

Resumen

Dirty Frag no es una vulnerabilidad “remote one-click”, pero aumenta mucho el riesgo tras una intrusión. Si un atacante puede ejecutar código local con pocos privilegios, CVE-2026-43284 y la superficie asociada a rxrpc pueden permitir escalada a root.

Para administradores, la prioridad no es estudiar PoC. La prioridad es confirmar exposición del kernel, instalar actualizaciones de seguridad de la distribución y reiniciar, evaluar mitigaciones de bloqueo de módulos antes de la ventana de parcheo, e inspeccionar sistemas expuestos o sospechosos en busca de problemas de integridad y persistencia.

Referencias: