Qué ha pasado

Un fallo que llevaba más de diez años escondido en OpenSSH permite entrar por SSH escribiendo la contraseña mal. No es una forma de hablar: envías una contraseña larga y basura, y el servidor te abre —incluso en cuentas bloqueadas o de sistema, esas que se supone que nadie puede usar—. Se llama «sshole» (CVE-2026-123158) y se corrigió el 5 de noviembre en OpenSSH 10.6p2.

Y no afecta solo a «servidores raros». Afecta a todo lo que se construye sobre musl sin PAM: Alpine Linux —la base de medio Docker del mundo— pero también OpenWrt, Buildroot y Yocto, es decir, routers y dispositivos embebidos. Precisamente los cacharros que llevan años encendidos en un rincón y que nadie actualiza ni se para a comprobar.

Y lo urgente, con nombre y fuente: según la firma de inteligencia Previdian —recogido por The Hacker News—, el primer ataque real llegó en menos de nueve horas tras publicarse el fallo, con acceso de administrador (root) confirmado sobre un honeypot con Alpine. No es teoría: está pasando.

Míralo por dentro

Antes de los comandos, mira cómo funciona. Abajo tienes el ataque paso a paso: a la izquierda, lo que pasa; en el centro, lo que envía el atacante; a la derecha, lo que responde el servidor. Cámbialo a «Corregido» y verás dónde se rompe la cadena.

El mecanismo: por qué una contraseña mal abre la puerta

Aquí está lo que lo convierte casi en una broma. En los sistemas afectados, la librería de sistema (musl) tiene una función, crypt(), que cifra la contraseña que tecleas para compararla con la guardada. Pero musl corta la entrada en 256 bytes —una defensa contra ataques que agotan la CPU— y, cuando le llega una contraseña de más de 256 caracteres, en vez de dar un error claro devuelve el carácter *.

¿Y qué significa * en el fichero de contraseñas (/etc/shadow)? Justo eso: una cuenta bloqueada o sin contraseña, de las que nadie debería poder usar. Así que OpenSSH acaba comparando dos cosas: el * que crypt() devuelve por la contraseña demasiado larga, y el * que marca la cuenta bloqueada. Coinciden. Y da el acceso por bueno.

El resultado: enviando una contraseña de entre 257 y 1.024 caracteres contra una cuenta cuyo campo en shadow es exactamente *, entras. Sin adivinar nada, sin fuerza bruta, sin millones de intentos. El candado no falló por fuera: comparó mal por dentro.

¿Y el papel de PAM? Cuando PAM está activo, OpenSSH ni siquiera usa esa ruta de crypt(): delega la autenticación en PAM y el fallo no se dispara. Por eso «sin PAM» es una condición necesaria —no porque PAM sea «una segunda comprobación», sino porque evita por completo el camino roto.

No es solo Docker: routers y cacharros que nadie mira

La parte incómoda es el alcance. El fallo vive en cualquier OpenSSH anterior a 10.6p2 compilado sobre musl y sin PAM, y eso abarca mucho más que un contenedor:

• Alpine Linux — la base de una parte enorme de los contenedores en producción.
• OpenWrt (cuando se instala openssh, no el Dropbear que trae por defecto) — routers y puntos de acceso.
• Buildroot y Yocto compilados con musl — dispositivos embebidos e IoT a medida.

Traducción: no hablamos solo de servidores web en contenedores, sino de infraestructura de red y aparatos que llevan años encendidos sin que nadie los toque. Son justo los sistemas que no entran en ningún inventario, que no tienen quien los actualice y que nadie se para a comprobar. Ahí es donde un fallo así hace más daño: en lo que damos por hecho.

Las distribuciones «de toda la vida», con glibc y PAM por defecto —Ubuntu, Debian, Red Hat, AlmaLinux, CentOS—, no están expuestas en su configuración habitual. Por eso la pregunta correcta no es «¿uso OpenSSH?» —lo usa todo el mundo— sino «¿tengo algún sistema sobre musl, con SSH por contraseña y sin PAM?». Y la respuesta honesta, para la mayoría, es: no lo sé sin mirar.

Cómo saber si te afecta

Cuatro comprobaciones. Ninguna ataca nada: solo leen el estado de tu propio sistema.

# 1 · versión de OpenSSH — segura desde la 10.6p2
ssh -V
# en Alpine, mira el paquete:
apk info openssh 2>/dev/null | head -1

# 2 · ¿musl? (Alpine, OpenWrt, Buildroot/Yocto con musl)
ldd /bin/ls 2>&1 | head -1    # "musl" = afectado · "ld-linux"/"glibc" = no

# 3 · ¿PAM desactivado y login por contraseña activo? (las dos = expuesto)
grep -iE '^\s*(UsePAM|PasswordAuthentication)' /etc/ssh/sshd_config

# 4 · ¿hay cuentas con '*' (bloqueadas) que el fallo podría abrir?
awk -F: '$2=="*"{print $1}' /etc/shadow 2>/dev/null

La trampa de Docker. Si lanzas ssh -V en el servidor anfitrión, te da la versión del anfitrión —que casi siempre es Ubuntu con glibc y parece seguro—. Pero el fallo vive dentro del contenedor Alpine, que es otro mundo. Entra al contenedor y repite ahí las comprobaciones. Lo mismo con un router: la versión que importa es la que corre dentro del cacharro, no la que recuerdas.

Qué hacer, por orden

1. Actualiza OpenSSH a 10.6p2 o superior y reinicia el servicio (o recrea el contenedor). En Alpine hay paquetes corregidos en todas las ramas desde la 3.16. Es la solución de verdad.
2. Si no puedes actualizar ya, rompe una de las condiciones: desactiva el login por contraseña (PasswordAuthentication no) o activa PAM (UsePAM yes) y reinicia. Cualquiera de las dos corta el ataque.
3. En routers y dispositivos embebidos, que son los que nadie revisa: míralos de verdad. Si no hay actualización disponible, al menos cierra el puerto 22 a quien no lo necesite. Un filtro que solo deje entrar a tus IPs convierte un fallo de internet entero en un fallo de tu oficina.

La lección que no caduca

sshole llevaba más de diez años ahí, en un mecanismo tan básico como comparar una contraseña. El mismo OpenSSH es seguro sobre glibc y vulnerable sobre musl sin PAM: no fallaba el candado, fallaba la combinación de piezas. Y lo más caro no fue el fallo en sí, sino dónde vivía —en los sistemas que nadie mira—.

Deja una pregunta incómoda, y es la que de verdad merece la pena llevarse: ¿cuántos sistemas damos por seguros simplemente porque llevan años funcionando sin que nadie haya descubierto cómo romperlos? La seguridad no es un estado que se alcanza; es saber qué corre dónde, en qué versión y con qué configuración. Esa foto —que casi nadie tiene— es la diferencia entre enterarte de un fallo así en diez minutos o no enterarte nunca.

Si no sabes si alguno de tus servidores, contenedores o routers cumple las condiciones, escríbenos y lo miramos contigo. Es media hora, y te quedas sabiendo exactamente de qué lado estás.

Fuentes

Todo lo que se afirma aquí sale de estas fuentes. Si solo vas a abrir una, que sea la primera.

• NVD — CVE-2026-123158, la ficha oficial (CVSS 8.1). La fuente primaria.
• CISA — Catálogo de vulnerabilidades explotadas (KEV), donde entró por explotación activa.
• StepSecurity — el mecanismo: crypt() de musl devuelve * con contraseñas de más de 256 bytes, y * es el marcador de cuenta bloqueada.
• The Hacker News — explotado en horas, root en un honeypot (el dato de Previdian, menos de 9 horas).
• GBHackers — acceso a cuentas con contraseña deshabilitada usando contraseñas de 257 caracteres.
• Safe Security — cómo convierte contraseñas deshabilitadas en acceso no autorizado.

De la misma serie

• WordPress: cuando actualizar es, justo, lo que te deja entrar
• Node2Shell: el fallo no es de Node, es de Brotli
• Cuatro avisos críticos en ocho días: nginx, el kernel, PHP y Node

Si no sabes si alguno de tus servidores, contenedores o routers cumple las condiciones, en MagicBoxDesk lo revisamos contigo: ciberseguridad y mantenimiento web gestionados. 📍 Alicante y Barcelona · hablemos 30 minutos.