SSHole: en servidores Alpine, una contraseña de más de 256 caracteres abre SSH sin conocer la clave; OpenSSH 10.6p2 lo corrige y se esperan escaneos este fin de semana

El jueves 5 de noviembre, el proyecto OpenSSH publicó la versión 10.6p2 con lo que sus propias notas llaman un "arreglo crítico" para sistemas Linux que usan la librería musl y tienen PAM desactivado. La falla ya tiene número, CVE-2026-123158, y apodo: SSHole. El viernes 6 la retomaron medios como SecurityWeek, y ahí dos investigadores advirtieron que los escaneos en busca de servidores vulnerables podían empezar en horas, con intentos de ataque este mismo fin de semana.

Si tu empresa tiene un servidor, un VPS o un contenedor con Alpine Linux y SSH abierto a internet, este sábado conviene revisarlo.

Qué pasa exactamente

El servidor SSH (sshd) revisa la contraseña con una función del sistema llamada crypt(). En la librería musl, cuando la contraseña es muy larga, esa función devuelve un asterisco (*). Y en muchos sistemas, el asterisco es justamente lo que aparece en el archivo de contraseñas de las cuentas que no tienen contraseña. Resultado: sshd compara asterisco contra asterisco y deja pasar.

En palabras del registro oficial de la CVE: en ciertas configuraciones de cuentas, cualquier contraseña de entre 256 y 1,024 caracteres es aceptada. El aviso de Alpine habla de 257 a 1,024 bytes; la diferencia es de un carácter y no cambia nada práctico. No se necesita fuerza bruta: según Alpine, basta un solo intento.

OpenSSH aclara que considera que la causa de fondo está fuera de sshd (en la librería), pero que se puede explotar a través de sshd y por eso la cerró ahí.

¿Mi servidor es vulnerable?

El aviso de Alpine pide que se cumplan todas estas condiciones:

1. Usas el paquete openssh-server sin PAM, o la variante con PAM pero con UsePAM no.
2. PasswordAuthentication está en yes, que es el valor de fábrica.
3. Hay al menos una cuenta cuyo campo de contraseña es *. Ahí entran root en las imágenes base desde aproximadamente la 3.16, los usuarios que solo entran con llave SSH, los usuarios que vienen de un directorio (LDAP o Active Directory vía sssd, winbind o nslcd) y el usuario alpine de las imágenes de nube.
4. Hay al menos una cuenta local con contraseña real (un hash que empieza con $5$ o $6$).

No están afectados, según Alpine: los contenedores que no corren sshd, los sistemas con PasswordAuthentication no, las cuentas bloqueadas con ! y las imágenes con cloud-init que ya apagan las contraseñas.

Fuera de Alpine, el registro de la CVE cubre cualquier Linux con musl y OpenSSH sin PAM. Eso incluye firmware armado con Buildroot o Yocto si trae OpenSSH. Red Hat indicó que sus productos no están afectados porque usan glibc y PAM; Debian y Ubuntu tampoco lo están en una instalación normal.

El caso que más preocupa: imágenes de nube

Alpine advierte que sus imágenes oficiales de nube (las que se usan en AWS, Azure o en hipervisores locales) publicadas de la 3.18.11 a la 3.24.3 traen un usuario alpine sin contraseña y con permiso para volverse administrador sin pedir clave. Son seguras al primer arranque, pero si alguien le pone contraseña a cualquier otra cuenta, el usuario alpine queda expuesto y, desde ahí, el control total de la máquina está a un comando.

Las imágenes construidas desde las versiones 3.21.10, 3.22.8, 3.23.8 y 3.24.4 ya traen el paquete corregido.

Versiones corregidas de Alpine

Alpine sacó paquetes corregidos para todas sus ramas, incluso las que ya no tienen soporte:

Que haya parche para la 3.21 no cambia lo que contamos hace unos días: esa rama se quedó sin parches el 1 de noviembre y el plan sigue siendo migrar.

¿Ya hay ataques?

Las fuentes coinciden en que todavía no se han reportado ataques reales:

• CISA no la ha metido a su catálogo de vulnerabilidades explotadas (KEV); su revisión automática la marca con prueba de concepto disponible e impacto técnico total.
• Desde el 5 de noviembre hay al menos un repositorio público en GitHub para reproducir la falla, y ese mismo día el escáner de código abierto de Google agregó la detección de CVE-2026-123158.
• En la nota de SecurityWeek del 6 de noviembre, Fredrik Almroth, de Detectify, recordó que Shodan ve unos 22 millones de equipos con SSH en el puerto 22 y anticipó escaneos en cuestión de horas; Jake Knott, de watchTowr, dijo esperar intentos de ataque durante el fin de semana.

Esos 22 millones son todos los SSH visibles, no los vulnerables: nadie ha publicado cuántos corren Alpine sin PAM. Pero con una falla que se explota en un intento, no conviene esperar al lunes.

Qué hacer hoy

1. Haz la lista. Identifica servidores, VPS y contenedores con Alpine que corren sshd. En cada uno, cat /etc/alpine-release te da la versión y apk info -v openssh-server la del paquete. No olvides equipos que traen Linux por dentro y SSH habilitado: pregúntale al proveedor si usan musl y OpenSSH sin PAM.
2. Actualiza y reinicia. En Alpine: apk upgrade -U -a y después rc-service sshd restart. Actualizar el paquete no reemplaza el proceso que ya está corriendo.
3. Si no puedes actualizar, apaga las contraseñas. Crea un archivo en /etc/ssh/sshd_config.d/ con PasswordAuthentication no (Alpine lee esa carpeta desde la 3.19) y cambia a no cualquier línea igual en /etc/ssh/sshd_config, incluidas las de bloques Match. Valida con sshd -t y reinicia. Antes, confirma que entras con llave y deja una sesión abierta.
4. Comprueba. sshd -T | grep -i passwordauthentication debe responder passwordauthentication no si aplicaste la mitigación.
5. Reconstruye las imágenes de contenedor que incluyan sshd. Una imagen armada antes del parche sigue vulnerable aunque el servidor anfitrión esté al día.
6. Busca huellas. Alpine sugiere revisar en /var/log/messages los Accepted password for de cuentas que no deberían tener contraseña (alpine, root o usuarios que solo usan llave), además de usuarios nuevos, llaves autorizadas agregadas y uso de doas. Si no puedes descartar un acceso, trata la máquina como comprometida.

La lección para la PyME

Dejar SSH abierto a todo internet, y encima con contraseña, es una apuesta que pierde cada vez que sale una falla así. Lo sano es entrar solo con llaves, limitar el puerto a las IP de la oficina o meterlo detrás de una VPN o un acceso Zero Trust. Y llevar un inventario de qué corre en cada contenedor, el mismo que esta semana hacía falta para encontrar Brotli dentro de Node.js y .NET o para la falla del kernel de Linux de octubre. Si tus contenedores salen de un docker-compose, reconstruirlos con la imagen nueva es cuestión de minutos.

Fuentes: notas de la versión 10.6p2 de OpenSSH (5 de noviembre), aviso de seguridad de Alpine Linux (5 de noviembre), mensaje en la lista oss-security de Openwall (5 de noviembre), registro CVE-2026-123158 de MITRE y su ficha en NVD, SecurityWeek (6 de noviembre) y GitHub.