Nueve años con la puerta abierta: un fallo imperceptible en el kernel comprometió la seguridad de Linux

Durante nueve años, en el núcleo de Linux permaneció un error que podría convertir un acceso local ordinario en control total sobre el sistema. El problema afecta las instalaciones estándar de distribuciones populares y ya existe un ejemplo de explotación funcional, por lo que los administradores deberán comprobar rápidamente las actualizaciones y posibles rastros de filtraciones.

La vulnerabilidad recibió el identificador CVE-2026-46333 y una puntuación de 5,5 en la escala CVSS. El equipo de Qualys vinculó el problema a una gestión incorrecta de privilegios en la función __ptrace_may_access(). El error apareció en noviembre de 2016 y permaneció sin ser detectado durante mucho tiempo.

Según Qualys, un usuario local sin privilegios elevados podía acceder a archivos sensibles y ejecutar comandos arbitrarios con privilegios root. Entre los sistemas afectados se mencionan las instalaciones estándar de Debian, Fedora y Ubuntu. La vulnerabilidad también es conocida como ssh-keysign-pwn.

Said Abbasi, de Qualys, explicó que el mecanismo encontrado funciona de forma fiable y permite convertir una shell local ordinaria en una vía para obtener acceso root o para acceder a credenciales privadas. Un ataque exitoso podría revelar el contenido de /etc/shadow, las claves SSH privadas del host ubicadas en /etc/ssh/_key, y también permitir ejecutar comandos mediante scripts de ataque contra chage, ssh-keysign, pkexec y accounts-daemon.

La información sobre el problema apareció poco después de la publicación de un exploit PoC funcional y de un cambio abierto en el código del núcleo. CVE-2026-46333 se convirtió en otro hallazgo serio en Linux del último mes tras Copy Fail, Dirty Frag y Fragnesia.

Qualys recomienda instalar las actualizaciones recientes del núcleo proporcionadas por los mantenedores de las distribuciones. Si no es posible actualizar con rapidez, una medida temporal puede ser aumentar el valor de kernel.yama.ptrace_scope a 2.

En los servidores donde durante la vigencia del error trabajaron usuarios locales no confiables, conviene considerar que las claves SSH del host y las credenciales guardadas localmente pueden haber quedado expuestas, luego reemplazar las claves y comprobar los datos administrativos que pudieran haber estado en la memoria de procesos set-uid.