SSHole OpenSSH ya tiene explotación confirmada y dejó de ser un aviso para administradores pacientes. Previdian detectó el primer intento menos de nueve horas después de publicarse el CVE-2026-123158 y confirmó acceso root en un servidor señuelo con Alpine Linux y OpenSSH reales.
El cambio de estado es el dato. La nota del 5 de noviembre sobre el fallo de OpenSSH en Alpine Linux cerró con una frase clara: no había explotación reportada. Dos días después esa frase ya no se sostiene, y el margen para parchear con calma se acabó.
Menos de nueve horas: así cayó el señuelo
Ryan Dewhurst, fundador de Previdian, contó a Help Net Security que los sensores de la firma captaron ataques dirigidos a este fallo y que al menos uno llegó hasta el final. La dirección de origen observada, 89.116.89[.]18, ubicada en Japón, usó contraseñas sobredimensionadas para saltarse la autenticación y ejecutó comandos de reconocimiento (id, uname y hostname) en sesiones SSH sin interacción humana.
El conteo sigue siendo chico: ocho intentos, todos desde esa dirección y detectados por un solo sensor. Pero la intención ya no se discute. Decipher reportó que watchTowr vio redes de bots probando el fallo horas después de la divulgación, el barrido típico en busca de servidores olvidados.
Previdian metió el fallo en su propia lista de vulnerabilidades explotadas. CISA, la agencia de ciberseguridad de Estados Unidos, todavía no lo suma a su catálogo KEV de fallos explotados conocidos. Dewhurst atribuyó la velocidad a dos factores: explotar SSHole OpenSSH es trivial y los atacantes trabajan cada vez más rápido con ayuda de inteligencia artificial. Esa explotación confirmada convierte el parche del miércoles en tarea de hoy.
El mecanismo explica esa facilidad. Las cuentas sin contraseña usable guardan un asterisco en el campo de clave del archivo /etc/shadow. Cuando alguien ofrece una contraseña de entre 257 y 1.024 caracteres, la función crypt() de musl, la biblioteca de C sobre la que se construye Alpine, devuelve ese mismo asterisco como señal de error, sshd compara asterisco contra asterisco y abre la sesión. Özgün Kültekin, investigador de Wakefield, lo encontró tras lanzar unas 17.600 pruebas contra sshd compilado en cada combinación que se le ocurrió, con enjambres de agentes de IA como ayuda declarada por él mismo.
La raíz viene de lejos. En 2016, para corregir un fallo de temporización que dejaba adivinar qué usuarios existían en un servidor (CVE-2016-6210), OpenSSH cambió sshd para tomar prestada la sal de otra cuenta y procesar la contraseña de todos modos cuando la cuenta destino no tiene una clave válida. Esa decisión quedó cruzada con musl, que desde 2012 rechaza claves SHA-256 y SHA-512 de más de 256 caracteres.
Quién sigue expuesto y qué revisar hoy
El fallo alcanza a OpenSSH en versiones anteriores a la 10.6p2 en sistemas Linux con musl y sin PAM, los módulos de autenticación conectables que la mayoría de las distribuciones usa para revisar contraseñas. Alpine arma su paquete openssh-server por defecto justo así, y Kültekin sumó a la lista de sistemas a revisar OpenWrt, Buildroot y Yocto, más buena parte de las imágenes de contenedores que circulan en registros públicos.
El punto más delicado está en la nube. En las imágenes oficiales de Alpine para AWS y Azure, el usuario alpine tiene doas sin contraseña, el sustituto de sudo en ese ecosistema: entrar ahí equivale a ser root. SOCRadar acotó las imágenes tiny-cloud afectadas entre las versiones 3.18.11 y 3.24.3. La cuenta root de Alpine trae el asterisco desde la rama 3.16, protegida por el ajuste por defecto que prohíbe su acceso directo con contraseña, salvo que un administrador lo haya cambiado.
Fuera del radio quedan las distribuciones con glibc (Debian, Ubuntu y Fedora, entre otras), cualquier instalación que revise contraseñas con PAM, Dropbear y OpenBSD. Tampoco basta con que el puerto SSH esté abierto: el ataque pide acceso con contraseña activado, que es el ajuste por defecto de OpenSSH, una cuenta con el asterisco y otra cuenta local con una clave real de la que sshd pueda tomar la sal.
La corrección existe desde el 5 de noviembre: OpenSSH 10.6p2, y Alpine empujó paquetes parcheados para cada rama desde la 3.16 hasta edge el mismo día. Instalar la actualización no cierra nada por sí sola, porque el sshd que ya corre en memoria sigue aceptando conexiones con el código viejo hasta que el servicio se reinicia. Damien Miller, desarrollador de OpenSSH, pidió en Mastodon cortar por lo sano a quien no pueda parchear de inmediato: fijar PasswordAuthentication en no o apagar SSH en esos sistemas.
Detectar una entrada previa tiene una pista concreta. SOCRadar recomienda buscar en /var/log/messages las entradas «Accepted password for» asociadas a cuentas que no usan contraseña, como alpine, root o usuarios de solo llave, y revisar el uso de doas, los usuarios creados hace poco y los archivos authorized_keys. Si un acceso de ese tipo no se puede descartar, la máquina se trata como comprometida, no como sospechosa.
Las pruebas de concepto publicadas en GitHub tampoco son refugio: Previdian advirtió que no están verificadas y pueden traer malware. Con las redes de bots barriendo el puerto 22, el reloj corre para cada Alpine que siga sin reiniciar su sshd.
Fuente: Help Net Security
