Una nueva vulnerabilidad del kernel de Linux ha encendido las alertas en administradores de sistemas, proveedores de hosting y equipos de seguridad. El fallo, identificado como CVE-2026-46333 y apodado “ssh-keysign-pwn” por uno de los exploits públicos, permite que un usuario local sin privilegios lea archivos propiedad de root en determinadas condiciones. Entre los objetivos más sensibles están las claves privadas del host SSH y la base de datos /etc/shadow, donde se almacenan los hashes de contraseñas del sistema.
El problema no es una escalada directa a root en el sentido clásico. No concede por sí mismo una shell administrativa inmediata. Pero esa distinción se vuelve casi académica en muchos entornos reales: si un atacante consigue leer claves privadas SSH o hashes de contraseñas, puede avanzar hacia suplantación de servidores, descifrado offline, movimiento lateral o compromiso de otros sistemas. En infraestructuras compartidas, servidores multiusuario, entornos de hosting y máquinas con acceso local de terceros, el riesgo es especialmente serio.
NVD publicó la entrada de CVE-2026-46333 el 15 de mayo de 2026, aunque en el momento de la revisión todavía no había asignado una puntuación CVSS. La descripción oficial procede de kernel.org y apunta a un cambio en la lógica de get_dumpable() dentro del subsistema ptrace. El parche llegó al árbol principal del kernel el 14 de mayo de 2026 mediante el commit 31e62c2ebbfd, según recogen AlmaLinux, Red Hat y otros avisos de seguridad.
Una carrera en ptrace con consecuencias incómodas
La vulnerabilidad se encuentra en la función __ptrace_may_access(), usada por el kernel para decidir si un proceso puede inspeccionar o interactuar con otro. ptrace es una pieza muy sensible del sistema: se utiliza en depuradores, herramientas de diagnóstico y trazado, pero también puede convertirse en una vía peligrosa si las comprobaciones de permisos fallan.
El fallo aparece durante la salida de un proceso. En esa fase, el kernel libera antes el contexto de memoria del proceso (mm) que su tabla de descriptores de archivo. Durante una ventana muy breve, el proceso ya no tiene contexto de memoria asociado, pero todavía conserva archivos abiertos. Según la descripción técnica publicada por AlmaLinux y Red Hat, __ptrace_may_access() omite una comprobación relacionada con la “dumpability” cuando task->mm es NULL. Esa lógica permite que un proceso no privilegiado capture descriptores de archivo abiertos por un proceso privilegiado que se está cerrando.
El mecanismo que hace práctico el ataque es pidfd_getfd(2), una interfaz que permite duplicar descriptores de archivo de otro proceso bajo ciertas condiciones. En un sistema vulnerable, un atacante local puede intentar ganar esa carrera contra binarios privilegiados que abren archivos sensibles durante su ejecución normal. Los ejemplos más citados son ssh-keysign, que puede acceder a las claves privadas del host SSH, y chage, que interactúa con información de contraseñas.
La consecuencia es clara: el atacante no necesita romper directamente los permisos del archivo. Le basta con copiar el descriptor abierto por un proceso que sí tenía permiso legítimo para leerlo. Es una forma de fuga de información que rompe una expectativa básica del sistema: que un archivo propiedad de root no pueda ser leído por un usuario sin privilegios.
El caso resulta más llamativo porque la forma general del problema no era completamente desconocida. Red Hat recoge que Jann Horn ya había señalado una clase similar de robo de descriptores en octubre de 2020. La corrección actual intenta hacer más coherente el uso de la “dumpability” cuando el proceso ya no tiene un contexto de memoria asociado.
Por qué preocupa tanto en servidores
La explotación requiere presencia local. Esto significa que un atacante necesita ejecutar código en el sistema vulnerable, aunque sea con una cuenta sin privilegios. En un ordenador personal monousuario, el impacto dependerá mucho del contexto. En servidores compartidos, plataformas de hosting, bastiones SSH, entornos de desarrollo multiusuario o máquinas donde terceros pueden ejecutar procesos, el escenario cambia por completo.
La lectura de claves privadas SSH del host puede permitir ataques de suplantación si esas claves no se rotan después del incidente. Un atacante que obtenga la clave privada de un servidor podría hacerse pasar por esa máquina ante clientes que ya confían en su fingerprint, al menos hasta que se sustituyan las claves y se actualicen las huellas conocidas. Esto puede abrir la puerta a ataques de hombre en el medio en redes mal controladas o a campañas más dirigidas contra administradores.
El acceso a /etc/shadow tampoco debe subestimarse. Ese archivo no contiene las contraseñas en claro, pero sí hashes. Si las contraseñas son débiles o reutilizadas, un atacante puede intentar romperlas fuera de línea sin generar más ruido en el servidor. Una vez obtenida una contraseña válida, el salto a otros sistemas puede ser mucho más sencillo, sobre todo en organizaciones donde se repiten credenciales o no se aplica autenticación multifactor en todos los accesos.
CloudLinux ha descrito el fallo como una carrera en la ruta de salida del kernel y advierte de que existe una prueba de concepto pública. También explica que no todos los kernels antiguos son igual de explotables con el PoC actual, porque depende de la disponibilidad de pidfd_getfd(2). Aun así, el problema lógico puede estar presente en ramas que requieran adaptaciones distintas para ser explotadas. Por eso varios proveedores están preparando o publicando parches incluso para versiones donde el exploit público no funciona directamente.
AlmaLinux ha confirmado kernels corregidos para sus ramas afectadas y señala que una actualización con reinicio aplica también correcciones recientes relacionadas con otros fallos del kernel. Debian también ha incorporado CVE-2026-46333 a su tracker de seguridad y NVD ya enlaza múltiples commits de kernel.org para distintas ramas estables.
Qué deberían hacer los administradores
La medida principal es actualizar el kernel en cuanto el proveedor de la distribución publique el parche correspondiente y reiniciar el sistema, salvo que se utilice una solución fiable de live patching que cubra expresamente CVE-2026-46333. No basta con actualizar paquetes de usuario: el fallo está en el kernel.
En sistemas críticos conviene además revisar si hay usuarios locales no confiables, cuentas antiguas, accesos de terceros, entornos compartidos o procesos que permitan ejecutar código en la máquina. En este tipo de vulnerabilidades, reducir la superficie local importa casi tanto como aplicar el parche.
Si hay sospecha razonable de explotación, la respuesta debe ir más allá de actualizar. Las claves privadas del host SSH de los servidores afectados deberían rotarse, especialmente en máquinas expuestas, bastiones, nodos de administración y sistemas con muchos usuarios. También conviene revisar huellas conocidas, automatizaciones, inventarios de claves y registros de acceso. En el caso de /etc/shadow, la exposición puede justificar un cambio de contraseñas de cuentas locales y una auditoría de políticas de autenticación.
Algunas mitigaciones temporales pasan por endurecer ptrace o desactivar espacios de nombres de usuario no privilegiados, pero no son sustitutos del parche. LWN recoge que kernel.yama.ptrace_scope = 2 puede no ser suficiente en ciertos escenarios si los espacios de nombres de usuario siguen habilitados, mientras que opciones más estrictas pueden romper flujos legítimos de depuración. Esto obliga a evaluar cada entorno con cuidado.
La enseñanza para equipos de sistemas es conocida, pero vuelve a ser urgente: los fallos locales del kernel no son secundarios. En infraestructuras cloud, entornos multiusuario y servidores compartidos, una vulnerabilidad local puede convertirse en una fuga de secretos con consecuencias amplias. Las claves SSH, los hashes de contraseñas y los descriptores abiertos por procesos privilegiados son piezas demasiado valiosas para asumir que un usuario sin privilegios no puede hacer daño.
ssh-keysign-pwn no es solo otro CVE en una semana cargada de parches. Es un recordatorio de que el aislamiento interno de Linux depende de detalles muy finos del kernel. Cuando uno de esos detalles falla, la diferencia entre “usuario local sin privilegios” y “acceso a secretos de root” puede reducirse a una carrera de milisegundos.
Preguntas frecuentes
¿Qué es CVE-2026-46333?
Es una vulnerabilidad del kernel de Linux en la lógica de acceso de ptrace. Permite que un usuario local sin privilegios lea archivos propiedad de root en determinadas condiciones.
¿Por qué se llama ssh-keysign-pwn?
El apodo procede de uno de los exploits públicos, que apunta a ssh-keysign para intentar leer claves privadas del host SSH.
¿Es una escalada directa a root?
No exactamente. El fallo permite leer secretos protegidos, como claves SSH o /etc/shadow. Eso puede derivar después en compromiso de cuentas, suplantación o movimiento lateral.
¿Cuál es la solución recomendada?
Actualizar el kernel con los parches publicados por la distribución y reiniciar. Si hay sospecha de exposición, también conviene rotar claves SSH y revisar contraseñas locales.
