sshole: fallo de OpenSSH en Alpine, actualiza ya

El proyecto OpenSSH publicó el 5 de noviembre la versión 10.6p2 para corregir CVE-2026-123158, apodado «sshole». El fallo permite iniciar sesión por SSH sin conocer la contraseña en sistemas Linux compilados con la biblioteca musl y sin PAM, que es justo la configuración por defecto de Alpine Linux. Tiene una puntuación CVSS 3.1 de 8,1 (alta) y ya hay pruebas de concepto públicas.

Conviene dejar claro el alcance desde el principio: no afecta a Debian, Ubuntu, Fedora ni a otras distribuciones basadas en glibc, ni a sistemas que validan contraseñas con PAM, ni a Dropbear u OpenBSD. Pero Alpine es la base de una enorme cantidad de imágenes Docker, routers y dispositivos embebidos, así que el número de equipos expuestos no es pequeño.

Qué ha pasado

5 de noviembre: Damien Miller anuncia OpenSSH 10.6p2 en la lista oss-security con una «corrección de seguridad crítica» para sistemas Linux con musl y PAM desactivado. El fallo lo descubrió Özgün Kültekin, de Wakefield.
5 de noviembre: Alpine publica paquetes corregidos para todas sus ramas con soporte, desde la 3.16 hasta edge, y los detalles técnicos se hacen públicos.
6 de noviembre: el GovCERT de Hong Kong emite una alerta de amenaza alta e indica que ya circula código de prueba de concepto.

Cómo funciona

En Linux, las cuentas que no deben aceptar contraseña (por ejemplo, un usuario que solo entra con clave SSH) suelen tener un * en el campo de la contraseña de /etc/shadow. Cuando la función crypt() de musl recibe una contraseña de más de 256 bytes, la rechaza devolviendo precisamente *. OpenSSH, en su camino sin PAM, comparaba ese resultado con lo guardado en /etc/shadow… y como ambos son *, daba la contraseña por buena.

Resultado: cualquier contraseña de más de 256 caracteres abre la puerta de las cuentas «sin contraseña». El propio equipo de OpenSSH considera que la raíz del problema está fuera de sshd, pero como se explota a través de él, lo ha corregido ahí: la versión 10.6p2 rechaza los hashes guardados que son demasiado cortos para ser válidos.

A quién afecta

Según los análisis de OX Security, SAFE Security y Help Net Security, un equipo es vulnerable solo si se cumplen todas estas condiciones:

OpenSSH anterior a 10.6p2 compilado con musl (Alpine, OpenWrt, Buildroot, Yocto y muchas imágenes Docker).
Sin PAM (el paquete openssh-server de Alpine no lo usa por defecto) y con el acceso por contraseña activado, que es la opción por defecto de OpenSSH.
Una cuenta con * como contraseña y, además, otra cuenta local con una contraseña real.

Las cuentas en riesgo son las que «nunca» deberían aceptar contraseña: usuarios de despliegue que solo usan claves, usuarios LDAP o el propio root, que en Alpine tiene * desde la versión 3.16 (aunque la opción por defecto PermitRootLogin impide entrar como root si no se ha cambiado). El caso más delicado son las imágenes oficiales de Alpine para AWS y Azure, cuyo usuario alpine puede usar doas sin contraseña: si el sistema es vulnerable, eso equivale a acceso de administrador. Las cuentas bloqueadas con ! en lugar de * no están afectadas.

¿Se está explotando?

Aquí las fuentes no coinciden, así que es mejor ser prudente con los titulares. La empresa Previdian asegura que detectó intentos menos de nueve horas después de la publicación y que un atacante llegó a conseguir acceso root en uno de sus señuelos con Alpine. SAFE Security, en cambio, afirmaba el 6 de noviembre que no se había confirmado explotación real, y CISA todavía no lo ha añadido a su catálogo de vulnerabilidades explotadas. Lo que sí confirman varias fuentes es que hay pruebas de concepto en GitHub; Previdian advierte de que no están verificadas y podrían contener código malicioso, así que no conviene ejecutarlas.

Qué hacer ya

Actualizar: en Alpine, apk upgrade -U -a y después rc-service sshd restart. Instalar el paquete no reinicia el sshd que ya está en marcha; sin el reinicio, sigues siendo vulnerable.
Comprobar la versión del paquete: corregidas a partir de 10.6_p2-r0 (edge), 10.3_p1-r2 (3.24), 10.2_p1-r1 (3.23), 10.0_p1-r11 (3.22), 9.9_p2-r1 (3.21), 9.7_p1-r6 (3.20) y 9.6_p1-r3 (3.19).
Si no puedes actualizar todavía: desactiva el acceso por contraseña. Es la medida que recomiendan tanto el aviso de oss-security como el propio Damien Miller: echo "PasswordAuthentication no" > /etc/ssh/sshd_config.d/00-no-passwords.conf, comprueba la configuración con sshd -t y reinicia sshd.
Reconstruir imágenes Docker: un contenedor basado en una imagen Alpine antigua con SSH no se corrige solo. Hay que reconstruirlo sobre la imagen actualizada.
Revisar los registros: busca líneas Accepted password for en /var/log/messages para cuentas que no deberían tener contraseña. Cualquier coincidencia debe tratarse como un compromiso.
No exponer SSH a Internet si no hace falta: mejor detrás de una VPN o limitado por cortafuegos a las redes de administración.

Qué vigilar a continuación

Si CISA lo incorpora a su catálogo KEV, lo que confirmaría la explotación real.
Las actualizaciones de imágenes Docker, firmware de routers y dispositivos embebidos basados en musl, que suelen tardar más que las distribuciones.
La ficha definitiva del NVD, que a día de hoy sigue pendiente de análisis.

No es el único susto reciente en servidores web: repasa PHP2Shell, los dos fallos críticos del núcleo de PHP.

Conclusión: sshole no es un fallo universal de SSH, pero en Alpine es de los que no admiten espera: basta una contraseña larga para entrar en cuentas que se suponían cerradas. Actualizar, reiniciar sshd y, mejor aún, dejar el acceso solo por clave cierra el problema.

«sshole»: un fallo en OpenSSH deja entrar por SSH con cualquier contraseña larga en Alpine Linux