Hackers explotan el fallo SSHole de OpenSSH para entrar en servidores Alpine Linux

Los atacantes ya explotan SSHole (CVE-2026-123158, gravedad 8,1 sobre 10), un fallo de OpenSSH que permite entrar en algunos servidores Linux con cualquier contraseña de más de 256 caracteres. Afecta a los sistemas basados en la biblioteca C musl, sobre todo Alpine Linux. La firma de inteligencia de amenazas GreyNoise registró la primera intrusión con éxito el 7 de noviembre a las 00:46 UTC, unas 40 horas después de publicarse el parche. Tras entrar, los intrusos buscaron contraseñas y claves, añadieron sus propias claves SSH y en un caso instalaron un agente de control remoto, informa BleepingComputer.

Cómo funciona el fallo

En Linux, un * en el campo de contraseña de /etc/shadow significa que no se puede entrar en esa cuenta con contraseña en absoluto. Alpine lo usa para root y para los usuarios que solo entran con clave. El investigador Özgün Kültekin, de Wakefield, que informó del error, lo rastreó hasta un cambio de musl de 2012: cuando su función de hash de contraseñas falla, devuelve * en lugar de un error. Y falla con cualquier contraseña de más de 256 bytes. Así, una contraseña muy larga da *, coincide con la cuenta bloqueada y sshd deja pasar al atacante. Con PAM activado, sshd no compara los hashes de esta forma, así que esos sistemas están a salvo.

El ataque necesita cuatro condiciones a la vez: sshd compilado con musl, PAM desactivado, acceso por contraseña permitido y al menos una cuenta con * en el campo de contraseña. En Alpine, las tres primeras son la configuración por defecto del paquete openssh-server, y root tiene * desde la versión 3.16. Las imágenes oficiales de Alpine para AWS y Azure incluyen además un usuario alpine que puede ejecutar órdenes como root sin contraseña, de modo que entrar con él da control total.

Qué hicieron los atacantes

OpenSSH publicó la versión 10.6p2 con el parche el 5 de noviembre. El análisis del investigador salió ese mismo día, y menos de una hora después había código de explotación en GitHub. GreyNoise vio 16 cadenas de ataque con éxito desde seis direcciones IP en los sistemas que vigila y subraya que es solo una parte de la actividad. Los intrusos comprobaron si estaban dentro de un contenedor, consultaron los servicios de metadatos de la nube, intentaron leer las claves SSH de root y /etc/shadow y añadieron sus claves a authorized_keys de root y del usuario alpine para conservar el acceso.

Un grupo obtuvo permisos de root, cambió la configuración DNS, arrancó un segundo servidor SSH oculto e instaló TAC Agent, un programa en Python con comentarios y mensajes en chino que puede ejecutar órdenes y mover archivos. Nunca logró registrarse en su servidor de control, tac.vpnla[.]org, y no recibió tareas. Las empresas de seguridad Previdian y Defused también registraron intentos, y watchTowr vinculó el fallo con botnets y minería de criptomonedas.

Cómo revisar tu servidor

• Mira qué sistema tiene: cat /etc/os-release. Si es Alpine u otro sistema con musl, sigue leyendo. Los servidores con Ubuntu y Debian no están expuestos a este fallo.
• Actualiza: apk upgrade openssh en Alpine. Hay paquetes corregidos para las ramas 3.19 a 3.24 y edge, según el registro de seguridad de Alpine.
• Si usas claves, desactiva el acceso por contraseña: PasswordAuthentication no en la configuración de sshd y reinicia sshd. Esto cierra el fallo incluso antes de actualizar.
• Busca rastros: accesos con contraseña correctos (grep "Accepted password" /var/log/messages) en cuentas con * en /etc/shadow, claves desconocidas en authorized_keys, los archivos /opt/py3/tac_agent.py y /etc/init.d/tac-agent, cambios en /etc/hosts y /etc/resolv.conf y un servidor SSH adicional en un puerto poco habitual (ss -tlnp muestra los puertos abiertos).
• Si encuentras algo de esto, da el servidor por comprometido: reinstálalo y cambia todas las contraseñas y claves que había en él.

Esto afecta a quien tenga su propia VPN en un VPS barato: las imágenes ligeras de Alpine son populares para eso. La mayoría de los routers domésticos con OpenWrt usan Dropbear para SSH y no están afectados, salvo que su dueño lo haya cambiado por OpenSSH. Nuestra guía para proteger un VPS ya recomienda entrar por SSH solo con clave, y esa opción bloquea el ataque.