sshole (CVE-2026-123158): La falla de OpenSSH que afecta a Alpine Linux y cómo solucionarla

Por Eoin Villarin, 2026-11-07

- Un fallo de OpenSSH llamado sshole permite a los atacantes iniciar sesión en cuentas sin contraseña en Alpine Linux y otros sistemas basados en musl, y ya está siendo explotado. ¿Quién está afectado, cómo comprobar tus servidores y cómo solucionarlo.

¿Estoy afectado por la falla de OpenSSH sshole?

Estás en riesgo si un servidor ejecuta OpenSSH anterior a 10.6p2 en un sistema basado en musl como Alpine Linux sin PAM, permite inicios de sesión con contraseña SSH y tiene una cuenta cuyo campo de contraseña es solo un asterisco junto a otra cuenta con un hash de contraseña real. Debian, Ubuntu, Fedora y configuraciones que usan PAM no están afectadas.

Aspectos clave

CVE-2026-123158, llamada sshole, permite a los atacantes iniciar sesión en cuentas sin contraseña en Linux basado en musl enviando una contraseña demasiado grande.
El paquete openssh-server predeterminado de Alpine Linux se ve afectado, mientras que los sistemas glibc como Ubuntu y las configuraciones que utilizan PAM no se ven afectados.
Los atacantes lo explotaron menos de nueve horas después de que se publicara y obtuvieron acceso de root en un honeypot.
La solución es OpenSSH 10.6p2 o el paquete parcheado de Alpine para tu rama, seguido de un reinicio de sshd.
Si no puedes actualizar todavía, establece PasswordAuthentication no y usa claves SSH.

Una falla recientemente divulgada en OpenSSH llamada sshole, rastreada como CVE-2026-123158, permite a los atacantes iniciar sesión en ciertas cuentas de Linux que no están destinadas a aceptar contraseñas en absoluto. Afecta a OpenSSH en sistemas basados en musl como Alpine Linux, se solucionó el 5 de noviembre de 2026 y los atacantes comenzaron a usarlo menos de nueve horas después de que se publicara. Si ejecutas servidores Alpine, imágenes de Docker basadas en Alpine con SSH o dispositivos pequeños en OpenWrt, revisa hoy mismo.

¿Qué es la falla sshole de OpenSSH?

En sistemas basados en musl, la función crypt() de la biblioteca C devuelve un solo asterisco (*) cuando falla al hash de una contraseña, por ejemplo, cuando la contraseña es más larga que su límite de 256 bytes. Muchos sistemas Linux también usan un solo * en el campo de contraseña para significar "esta cuenta no tiene contraseña". OpenSSH comparó los dos, vio *, y lo trató como una coincidencia. Enviar una contraseña demasiado grande fue suficiente para iniciar sesión en una cuenta sin contraseña.

El comportamiento se remonta a un cambio de 2016 en el manejo de contraseñas de OpenSSH. El investigador de seguridad Özgün Kültekin lo encontró usando agentes de IA que ejecutaron alrededor de 17,600 pruebas de autenticación. El CVE tiene una puntuación CVSS 3.1 de 8.1, que se califica como Alta, y la solución se envió en OpenSSH 10.6p2.

¿Estoy afectado?

Un servidor está en riesgo cuando todas estas condiciones son verdaderas:

Ejecuta OpenSSH anterior a 10.6p2 en un sistema basado en musl, como Alpine Linux, OpenWrt, Buildroot o Yocto.
sshd no usa PAM. Este es el valor predeterminado para el paquete openssh-server de Alpine.
Los inicios de sesión con contraseña SSH están habilitados, que es el predeterminado de OpenSSH.
Al menos una cuenta tiene solo * en su campo de contraseña, como un usuario solo con clave, junto a otra cuenta con un hash de contraseña real.

Las imágenes en la nube oficiales de Alpine para AWS y Azure desde la 3.18.11 hasta la 3.24.3 son un caso grave: incluyen un usuario alpine predeterminado sin contraseña y con doas sin contraseña, lo que significa que un inicio de sesión exitoso puede convertirse en root.

No afectado: sistemas basados en glibc como Debian, Ubuntu y Fedora, configuraciones que comprueban contraseñas a través de PAM, Dropbear y OpenBSD. Las cuentas con un hash de contraseña real no se pueden omitir de esta manera.

Cómo comprobar tus servidores

Ejecuta estos como root en cada servidor Alpine o contenedor que ejecute sshd:

Revisa la configuración de SSH: sshd -T | grep -i -E 'passwordauthentication|usepam'. Si la autenticación por contraseña está desactivada o PAM está activada, esta falla no se puede utilizar.
Comprueba el paquete instalado: apk list --installed | grep openssh, y compáralo con las versiones corregidas que se muestran a continuación.
Lista de cuentas sin contraseña: awk -F: '$2=="*" {print $1}' /etc/shadow.
Busca inicios de sesión en esas cuentas: grep "Accepted password" /var/log/messages. Un inicio de sesión con contraseña en una cuenta con * en su campo de contraseña significa que el servidor probablemente fue atacado.

Cómo arreglar CVE-2026-123158 en Alpine Linux

Alpine envió paquetes parcheados para cada rama desde la 3.16 hasta la edge el mismo día que se divulgó la información. Actualiza y reinicia sshd, porque instalar la actualización no reinicia el proceso en ejecución:

apk upgrade -U -a y luego rc-service sshd restart

Rama Alpine	Versión de openssh fijada
borde	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
3.20	9.7_p1-r6
3.19	9.6_p1-r3
3.18	9.3_p2-r4
3.17	9.1_p1-r7
3.16	9.0_p1-r6

Para Docker, reconstruye cada imagen que contenga openssh a partir de una imagen base fresca y redeployla. Ten en cuenta que algunas imágenes SSH en Docker Hub, como linuxserver's openssh-server, desactivan los inicios de sesión con contraseña por defecto, pero se exponen cuando se establece PASSWORD_ACCESS=true.

Las versiones de Alpine anteriores a la 3.16 no obtienen un paquete fijo. Actualízalas a una versión compatible o utiliza la solución alternativa que se muestra a continuación.

Solución rápida: desactiva los inicios de sesión con contraseña SSH

Si no puedes actualizar de inmediato, establece PasswordAuthentication no en /etc/ssh/sshd_config, reinicia sshd y ejecuta la comprobación sshd -T de nuevo. Asegúrate de que tu inicio de sesión con clave SSH funcione antes de hacer esto, o puedes bloquearte. La SSH solo con clave es un buen valor predeterminado para cualquier servidor de todos modos.

Qué hacer si crees que te han golpeado

Revisa el uso de doas, usuarios creados recientemente y cada archivo authorized_keys.
Revisa los procesos desconocidos, los trabajos cron y las conexiones salientes.
Si no puedes descartar un compromiso, trata el servidor como comprometido: reconstrúyelo a partir de una imagen limpia y rota cada contraseña, clave y token que contenía.
No descargues exploits de prueba de concepto de GitHub para probar tus servidores. Los investigadores advierten que algunos no están verificados y pueden contener malware.

Mantener los servidores parcheados es una gran parte de la mantenimiento del sitio web Lo hago para mis clientes. Si necesitas ayuda para comprobar tu alojamiento, configuración de Docker o configuración SSH, ponerse en contacto.

Preguntas frecuentes

¿Está Ubuntu o Debian afectado por sshole?

No. Debian, Ubuntu, Fedora y otros sistemas basados en glibc no están afectados, tampoco las configuraciones que usan PAM para comprobaciones de contraseña.

¿Me protege SSH solo con clave?

Sí. Con PasswordAuthentication configurado en no, el servidor no acepta contraseñas, por lo que la falla no se puede utilizar.

¿Se está explotando CVE-2026-123158?

Sí. La firma de inteligencia de amenazas Previdian vio el primer intento menos de nueve horas después de que se publicara el CVE, y un atacante obtuvo acceso root en uno de sus honeypots ejecutándose en Alpine Linux.

¿Qué versión de OpenSSH soluciona el problema?

OpenSSH 10.6p2. En Alpine, instala el paquete openssh parcheado para tu rama y reinicia sshd.

¿Están afectados los contenedores Docker?

Los contenedores basados en Alpine que ejecutan sshd con inicio de sesión con contraseña habilitado pueden estar afectados. Reconstrúyelos a partir de una imagen base actualizada y redeploy.

¿Necesito reiniciar después de actualizar?

Sí. El sshd en ejecución mantiene el código vulnerable en memoria hasta que reinicies el servicio.