Un atacante puede entrar sin contraseña a un servidor Alpine con OpenSSH mal configurado.
La falla se llama SSHole (CVE-2026-123158), ya se está explotando en internet y la solución es actualizar a OpenSSH 10.6p2 o desactivar el acceso por contraseña.
OpenSSH publicó el parche el 5 de noviembre. La vulnerabilidad tiene un CVSS de 8.1, según eSentire, y la reportó Özgün Kültekin, de Wakefield.
No afecta a todas las distribuciones: el problema aparece en sistemas Linux que usan la librería musl y tienen PAM desactivado, como Alpine, Buildroot, OpenWrt o Yocto. Ubuntu, Debian y Fedora, que usan glibc y PAM, quedan fuera.
Por qué una contraseña larga abre la puerta
El fallo está en cómo sshd compara la contraseña con el hash guardado. Si una cuenta tiene el campo de contraseña en * —lo normal en cuentas solo con llave—, sshd toma la sal de otra cuenta con hash $5$ o $6$.
Cuando la contraseña enviada supera los 256 bytes, la función crypt() de musl falla y devuelve * en lugar de un error. Ese * coincide con el valor almacenado y el login pasa.
En la práctica, el atacante necesita una cuenta sin contraseña, otra con hash válido y autenticación por contraseña activa. En Alpine, root viene con *, pero OpenSSH la protege con PermitRootLogin prohibit-password.
El riesgo real aparece si otra cuenta puede usar doas para escalar.
Ya hay intentos de explotación
Previdian registró 20 intentos de explotación desde 13 direcciones IP en nueve países entre el 6 y el 8 de noviembre, y confirmó acceso root en una honeypot con Alpine.
GreyNoise observó su primera explotación exitosa el 7 de noviembre, unas 40 horas después del parche, y WatchTowr atribuye los primeros ataques a botnets y mineros de criptomonedas.
No es masivo, pero tampoco es teoría: los botnets adoptan rápido las fallas que pueden monetizar. Si el servidor está expuesto, la ventana entre el parche y el ataque ya está abierta. Se suma a una semana movida: Claude Code filtró contraseñas en más de 1.100 repos públicos de GitHub.
Cómo saber si estás expuesto
- Revisa si corres
openssh-serveren Alpine o en otra distro con musl y PAM desactivado. - Confirma que
PasswordAuthenticationesté enyes. Es el valor por defecto de OpenSSH. - Busca cuentas con
*en el archivo de contraseñas del sistema y al menos otra con hash$5$o$6$. - Revisa
/var/log/messagespor líneasAccepted passworden cuentas que no tienen contraseña, y revisaauthorized_keys, usuarios nuevos y uso dedoas.
La solución, en orden
Actualiza con apk upgrade -U -a y reinicia el servicio con rc-service sshd restart. No basta con actualizar: el daemon sigue con la versión vieja hasta que lo reinicies. Las versiones corregidas son Alpine 3.21.10, 3.22.8, 3.23.8 y 3.24.4; en edge, OpenSSH 10.6_p2-r0. El detalle está en la advisory de Alpine.
Si no puedes actualizar ahora, desactiva el login por contraseña: PasswordAuthentication no en la configuración de sshd y reinicia. Antes de hacerlo, comprueba que tu llave funciona y deja abierta la sesión actual hasta probar un login nuevo. Los contenedores Docker que no ejecutan sshd no están afectados.
SSHole no rompe Ubuntu ni Debian, pero sí los Alpine de la nube, VPS e imágenes mínimas. ¿Tienes sshd con contraseñas activas en un contenedor que creías seguro?
Más en: Ciberseguridad, Programación
