OpenSSH en Alpine Linux: falla permite entrar sin contraseña

El 5 de noviembre de 2026, el proyecto OpenSSH publicó la versión 10.6p2 con una corrección crítica: en sistemas Linux que usan la biblioteca musl y funcionan sin PAM (el módulo que gestiona la autenticación), un atacante que alcance el puerto SSH puede entrar a ciertas cuentas sin conocer la contraseña. Alpine Linux, la distribución más conocida basada en musl, publicó el mismo día su aviso: «Basta una conexión, funciona siempre y no necesita reintentos». La falla la reportó Özgün Kültekin, de la firma Wakefield, y todavía no tiene identificador CVE.

Cómo funciona

Las cuentas sin contraseña, como las que solo entran con llave SSH, tienen un asterisco (*) en el archivo /etc/shadow. Para revisar la clave de una de esas cuentas, sshd toma prestada la sal (el valor aleatorio que acompaña al hash) de otra cuenta, así que debe existir al menos un usuario con contraseña real. Cuando la clave enviada supera 256 bytes, la función de musl que la cifra falla y devuelve justamente un asterisco, que coincide con el de la cuenta, y el servidor deja entrar al atacante. Por eso la falla permite entrar sin contraseña con cualquier texto de 257 a 1.024 caracteres. Su descubridor calcula que el problema existe desde 2016.

Quién está expuesto

Según el aviso de Alpine, un servidor Alpine es vulnerable si cumple todo esto:

• Usa el paquete openssh-server, que viene sin PAM, o openssh-server-pam con UsePAM no.
• Tiene activo PasswordAuthentication, el valor por defecto.
• Tiene una cuenta con *: usuarios que solo usan llave, usuarios de un directorio como LDAP, root (desde Alpine 3.16) o el usuario alpine de las imágenes oficiales para la nube.
• Tiene al menos una cuenta con contraseña cifrada con SHA-256 o SHA-512.

Root está protegido por la configuración por defecto PermitRootLogin prohibit-password, pero quien entre por otra cuenta con permisos de doas o sudo puede volverse administrador. Las versiones de Alpine afectadas van de la 3.16 a la 3.24. No están afectados los contenedores Docker que no ejecutan sshd, los sistemas con glibc (Debian, Ubuntu, Red Hat) ni los equipos que usan Dropbear en lugar de OpenSSH, como OpenWrt en su configuración por defecto. El mantenedor de musl advierte que está en riesgo cualquier sistema con musl y OpenSSH anterior a 10.6p2 sin PAM, lo que puede incluir equipos embebidos, como routers o NAS, que su fabricante haya construido sobre musl.

Qué hacer

1. En Alpine, ejecuta apk upgrade -U -a y reinicia sshd (rc-service sshd restart): actualizar el paquete no reemplaza el servicio que ya está corriendo. Las versiones 3.21.10, 3.22.8, 3.23.8 y 3.24.4 traen la corrección, y Alpine publicó paquetes corregidos hasta la 3.16.
2. Si todavía no puedes actualizar, desactiva el ingreso con contraseña (PasswordAuthentication no) y reinicia sshd, después de comprobar que tu llave SSH funciona.
3. Busca en /var/log/messages líneas «Accepted password» de cuentas que no tienen contraseña. Si no puedes descartar un ingreso, trata el servidor como comprometido.
4. Pregunta a los fabricantes de tus routers, NAS y equipos con Linux embebido si usan musl con OpenSSH, y aplica sus actualizaciones.
5. No dejes el puerto SSH abierto a todo internet: limítalo con el firewall o con una VPN.

Cómo te ayudamos

Con la gestión de servidores e infraestructura de Pronetsys aplicamos parches como este, dejamos el acceso SSH solo con llaves y lo restringimos en el firewall. Si tienes servidores o equipos Linux y no sabes si están expuestos, te ayudamos a revisarlos.

Fuentes

• Alpine Linux: aviso de seguridad de openssh-server (5 de noviembre de 2026)
• OpenSSH: notas de la versión 10.6p2 (5 de noviembre de 2026)
• musl: aviso para usuarios de OpenSSH con musl (5 de noviembre de 2026)
• Özgün Kültekin (Wakefield): explicación del hallazgo (noviembre de 2026)
• OpenWrt: paquetes incluidos por defecto