OpenSSH 10.6p2: el fallo que permite entrar por SSH con una contraseña muy larga en Alpine Linux

Publicado el 6 noviembre 2026 · Equipo mitza.es

SSH es la «llave maestra» con la que se administran la mayoría de servidores Linux: sirve para entrar en una máquina a distancia y ejecutar órdenes. Si alguien consigue saltarse su contraseña, el servidor queda en sus manos. El 5 de noviembre de 2026 el proyecto OpenSSH publicó la versión 10.6p2 y Alpine Linux difundió ese mismo día un aviso de seguridad sobre un fallo de este tipo. Lo resumimos a fecha de 6 de noviembre de 2026, ciñéndonos a lo que han publicado ambos proyectos.

Qué dicen OpenSSH y Alpine

Las notas de OpenSSH 10.6p2 hablan de corregir una omisión de la autenticación por contraseña explotable a través de sshd que «afecta a algunos sistemas Linux cuando se compilan y ejecutan con el soporte de PAM desactivado». El propio proyecto considera que la causa raíz está fuera de sshd, y describe la corrección como una medida de seguridad crítica para sistemas Linux con la biblioteca musl y PAM desactivado.

El aviso de Alpine, de la misma fecha, concreta el mecanismo: la función crypt() de musl devuelve el texto * como indicador de error cuando la clave supera los 256 bytes. Un atacante que envíe una contraseña muy larga (de 257 a 1.024 bytes) puede acabar autenticándose sin conocer la contraseña, siempre que se den dos condiciones: que exista una cuenta cuyo campo de contraseña sea * (una cuenta sin contraseña de acceso) y que haya al menos otra cuenta con una contraseña cifrada con hash de tipo $5$ o $6$. Según Alpine, el ataque funciona siempre y no requiere reintentos.

Esos detalles técnicos sirven para entender el riesgo; no hace falta que los memorices. Lo importante es la consecuencia: en configuraciones concretas, la contraseña deja de proteger el acceso.

A quién afecta

• Alpine Linux con el paquete openssh-server, que se compila sin PAM, y también con openssh-server-pam si tiene UsePAM no. Con openssh-server-pam y UsePAM yes no hay problema.
• Todas las versiones de Alpine revisadas: de la 3.21 a la 3.24 y edge, además de las antiguas sin actualizaciones regulares (3.16 a 3.20).
• Imágenes de nube de Alpine (tiny-cloud) desde la 3.18.11 hasta la 3.24.3 (formatos como qcow2, VHD o AMI), si en la máquina existe alguna contraseña con hash $6$.
• No afecta a quien use contenedores Docker en los que no se ejecute sshd. Si tienes un contenedor con un servidor SSH dentro, trátalo como cualquier otro servidor.

Alpine es habitual en contenedores y máquinas virtuales ligeras, y menos en servidores de uso general. Si tu empresa tiene un VPS, un servidor propio o un equipo de red, la pregunta útil es simple: ¿qué sistema operativo usa y está abierto el puerto SSH a internet? Si no lo sabes, pregúntalo a quien lo administra.

Versiones corregidas

OpenSSH corrige el fallo en la 10.6p2. En Alpine, los paquetes corregidos por rama son los siguientes:

• edge: 10.6_p2-r0
• 3.24: 10.3_p1-r2
• 3.23: 10.2_p1-r1
• 3.22: 10.0_p1-r11
• 3.21: 9.9_p2-r1

Alpine también publicó paquetes corregidos para las ramas más antiguas (3.16 a 3.20) y nuevas imágenes de nube a partir de las versiones 3.21.10, 3.22.8, 3.23.8 y 3.24.4. Revisa el aviso original de Alpine antes de actuar, que es la fuente que puede actualizarse. Reinicia el servicio SSH después de actualizar: según Alpine, actualizar el paquete no reinicia un sshd que ya estuviera funcionando, y mientras no se reinicie sigue en marcha la versión vulnerable (en Alpine, rc-service sshd restart).

¿Se está explotando?

Ni OpenSSH ni Alpine informan de ataques observados. Alpine indicaba además que, cuando escribió su aviso, aún no se había asignado un identificador CVE. Si ves otros datos en medios o paneles de vulnerabilidades (un número de CVE, una puntuación o referencias a ataques), contrástalos con los avisos oficiales de OpenSSH y Alpine antes de darlos por buenos. Conviene tratarlo igualmente como urgente: el ataque es sencillo y fiable según el propio aviso.

Qué hacer hoy: checklist

1. Identifica tus servidores con SSH accesible y su sistema operativo (cat /etc/os-release). Si usan Alpine, sigue los pasos siguientes.
2. Actualiza OpenSSH al paquete corregido de tu rama y reinicia sshd.
3. Si no puedes actualizar ya, desactiva el acceso por contraseña: pon PasswordAuthentication no en la configuración de sshd y reinicia el servicio. Según Alpine, cualquiera de las dos medidas (parche o desactivar contraseñas) cierra el hueco. Antes de hacerlo, asegúrate de tener acceso por claves o por otra vía, para no quedarte fuera.
4. Revisa los registros de acceso en busca de líneas «Accepted password for» de cuentas que no deberían poder entrar con contraseña. Es la pista que sugiere Alpine.
5. Si hay indicios de intrusión, cambia credenciales y claves, aísla el servidor y consulta con tu proveedor de informática o con el 017 de INCIBE.

Buenas prácticas de SSH que reducen estos riesgos

• Entra con claves, no con contraseñas. Desactiva la autenticación por contraseña siempre que sea posible; este fallo es una buena razón.
• Limita quién puede conectarse: cortafuegos que solo permita ciertas direcciones o una VPN, y AllowUsers para acotar cuentas. Es parte de lo que explicamos en qué es un firewall y qué necesita una pyme.
• Sin acceso directo como administrador (root): usa un usuario normal con permisos elevados.
• Herramientas contra intentos masivos como fail2ban, y alertas cuando entre alguien inesperado.
• Inventario y plazo máximo de parcheo para fallos críticos (por ejemplo, 48 horas).
• Copias de seguridad probadas, por si hubiera que reconstruir un servidor: regla 3-2-1.

Preguntas rápidas

¿Me afecta si uso Ubuntu, Debian o Red Hat?

El aviso de Alpine describe un problema de la combinación musl, que usa Alpine, con sshd sin PAM. Las distribuciones basadas en glibc que usan PAM no encajan en lo descrito, pero lo prudente es revisar el aviso de tu distribución y la versión de OpenSSH instalada. Y si el servidor se administra por contraseña, es un buen momento para pasar a claves.

¿Y si mi web está en un hosting compartido?

Entonces la administración del servidor es del proveedor. Puedes preguntarle si usa Alpine con SSH expuesto y cuándo aplica los parches de seguridad. Consulta también nuestra guía de dominio y hosting.

¿Y si tengo un NAS o un router con SSH activado?

El aviso de Alpine no los menciona, así que no podemos decir que te afecten. Pero muchos equipos de red y de almacenamiento funcionan con Linux, y el fabricante es quien publica sus parches: pregunta por el estado de SSH y desactívalo si no lo usas.

Cómo te ayudamos en Mitza

Hacemos inventario de servidores, revisamos accesos remotos y aplicamos parches y configuración segura de SSH. Mira cómo trabajamos en el mantenimiento informático para pymes o escríbenos desde la página de contacto.

Lectura relacionada: el fallo crítico del kernel de Linux CVE-2026-98432 y auditoría de seguridad web.