Un asterisco rompe la autenticación de OpenSSH

Tiempo de lectura: 6 minutos

OpenSSH publicó el 5 de noviembre de 2026 la versión Portable OpenSSH 10.6p2, esta version incluye una actualización de seguridad que corrige el bypass. El problema ha sido identificado como CVE-2026-123158. Esto afecta especialmente de los sistemas basados en musl libc, como Alpine Linux y entornos con BusyBox. Los sistemas operativos basados en musl libc son distribuciones de Linux que sustituyen la biblioteca estándar de C tradicional (glibc) por musl, una alternativa ligera, limpia y optimizada que la estandar de C, libc. A continuacion se explica como interactuan los componentes de OpenSSH para hacer el bypass y como mitigarlo.

Cómo verifica OpenSSH una contraseña sin PAM

Cuando OpenSSH utiliza PAM, la validación de credenciales se delega en la pila de autenticación del sistema. Sin PAM, sshd puede verificar directamente la contraseña utilizando crypt():

Si ambos valores coinciden, la contraseña se considera correcta. El problema aparece cuando el campo en /etc/shadow no contiene un hash.

El significado de * en /etc/shadow

El segundo campo de /etc/shadow almacena normalmente el hash utilizado para validar la contraseña de un usuario. Una cuenta normal puede tener una entrada similar a:

usuario:$6$...

Sin embargo, algunas cuentas configuradas exclusivamente para utilizar autenticación mediante claves SSH pueden contener:

usuario:*

Ese * no representa una contraseña válida. Su propósito es precisamente impedir que pueda existir una contraseña capaz de generar ese valor. Por tanto:

/etc/shadow = *

significa:

"esta cuenta no dispone de una contraseña válida"

Hasta aquí, el comportamiento es correcto y el que se espera. El problema surge porque musl puede utilizar el mismo carácter para representar un error.

Qué hace crypt() en musl

En determinadas condiciones, la implementación de crypt() incluida en musl libc devuelve ,*, cuando se produce un error:

*

Alpine Linux explica que este comportamiento de error puede aparecer cuando la contraseña enviada supera los 256 bytes. Tenemos entonces dos significados diferentes para el mismo valor:

/etc/shadow = *

significa:

contraseña deshabilitada

pero para:

crypt() = *

significa:

error durante el cálculo

El fallo aparece cuando ambos valores terminan siendo comparados directamente:

Cuando un error se interpreta como contraseña válida

Supongamos que existe una cuenta:

usuario:*

El atacante envía una contraseña suficientemente larga. Musl intenta procesarla mediante crypt() y devuelve *, como indicador de error:

*

El servidor acaba comparando:

valor almacenado = *
valor calculado  = *

Por tanto:

* == *

La comparación resulta positiva. En determinadas configuraciones, esto permite la autenticación.

Este es el núcleo técnico de CVE-2026-123158.

Condiciones requeridas para el bypass

El fallo tiene una gravedad importante, pero su alcance está bastante condicionado. Para que el escenario descrito sea explotable deben coincidir varias condiciones:

1.Linux con musl libc.
El comportamiento problemático depende de musl. Los sistemas Linux estándar basados en glibc no están afectados por esta vulnerabilidad concreta.

2.OpenSSH sin PAM.
Si PAM participa en la autenticación mediante contraseña, esta ruta de código no entra en juego.

3. PasswordAuthentication YES
La autenticación por contraseña debe estar habilitada.

4. Una cuenta cuyo campo de contraseña sea *.
La cuenta objetivo debe encontrarse en ese estado.

Alpine añade además una condición relacionada con el salt: debe existir en el sistema otra cuenta con un hash del tipo $ 5 $ o $ 6 $.

Alpine Linux el SO mas afectado

Alpine Linux utiliza musl libc, y sus paquetes habituales de OpenSSH encajan con las condiciones necesarias para reproducir el bypass. El proyecto confirmó que varias ramas mantenidas estaban afectadas antes de recibir las correcciones. Existe además un escenario sensible en algunas imágenes de Alpine donde determinadas cuentas utilizan * y posteriormente pueden disponer de privilegios elevados mediante mecanismos como doas.

Esto no significa que cualquier instalación Alpine sea automáticamente explotable, pero convierte a esta distribución en uno de los principales entornos que los administradores deberían revisar.

-Ejemplo de la explotación en un sistema Alpine Linux:

Root no es automáticamente vulnerable

Otro punto importante es evitar interpretar:

root:*

como equivalente a:

root vulnerable

OpenSSH utiliza habitualmente:

PermitRootLogin prohibit-password

Lo que impide el acceso de root mediante contraseña. Para que el fallo afectase a root tiene que existir además una configuración que permita la autenticación por contraseña para esa cuenta. Las cuentas bloqueadas mediante:

!

en lugar de:

*

tampoco entran en el escenario descrito.

Cómo corregir el problema, actualizar a Portable OpenSSH 10.6p2f

Actualiza la version de OpenSSH a la Portable OpenSSH 10.6p2. El paquete openssh-server de Alpine ya utiliza OpenSSH Portable

-Actualizar:
apk upgrade -U -a

-Reiniciar el servidor ssh
rc-service sshd restart

Importante: si administras Alpine mediante SSH, conserva abierta tu sesión actual hasta comprobar que puedes establecer una nueva conexión. En distribuciones como Alpine no es imprescindible ver exactamente la cadena:

10.6p2

porque el parche puede haber sido aplicado mediante backport a versiones anteriores. Por ejemplo en Alpine 3.24 incorpora el parche en su paquete 10.3_p1-r2 mediante un backport. Por tanto, revisar únicamente:

ssh -V

No siempre basta para determinar si el sistema continúa siendo vulnerable. Debe comprobarse también la versión exacta del paquete proporcionado por la distribución.

Si no es posible actualizar

Cuando no sea posible actualizar inmediatamente, hay que desactivar la autenticación mediante contraseña:

PasswordAuthentication no

Antes de hacerlo debe verificarse que existe otro mecanismo funcional de acceso, normalmente autenticación mediante clave pública. La configuración efectiva puede comprobarse con:

sshd -T | grep -i passwordauthentication

El resultado esperado:

passwordauthentication no

Después de actualizar OpenSSH también es importante recordar que instalar un paquete nuevo no sustituye automáticamente un proceso sshd que ya se encuentra en ejecución. El servicio debe reiniciarse para cargar el binario corregido. En Alpine:

rc-service sshd restart

Cómo revisar posibles indicios

Un administrador debería revisar especialmente autenticaciones aceptadas mediante contraseña para cuentas que teóricamente no deberían disponer de ella. Por ejemplo:

Accepted password for usuario

resultaría especialmente sospechoso si /etc/shadow contiene:

usuario:*

También conviene revisar cualquier modificación posterior en:

• usuarios;
• authorized_keys;
• configuraciones SSH;
• archivos del sistema;
• mecanismos de escalada de privilegios;
• registros de sesiones.

Si un servidor vulnerable ha permanecido expuesto y no puede descartarse un acceso no autorizado, debe tratarse como potencialmente comprometido.

Ademas los sistemas basados en Alpine, BusyBox o cualquier otra distribución que utilice musl deberían comprobar cuatro elementos:

-Versión del paquete OpenSSH

-Uso de PAM

-Estado de PasswordAuthentication

-Cuentas que contienen * en /etc/shadow.

Los sistemas Linux basados en glibc, los sistemas no Linux y los Linux que utilizan PAM para autenticar contraseñas quedan fuera del escenario descrito. Para los entornos afectados, la recomendación es facil: actualizar, reiniciar sshd y, siempre que sea posible, desactivar la autenticación mediante contraseña.

Cierre – OpenSSH ya había corregido otros problemas de autenticación en octubre

El bypass tratado aquí llega apenas un mes después de que OpenSSH publicara la versión 10.6, el 6 de octubre de 2026, con varias correcciones de seguridad. Entre ellas destacan CVE-2026-106553 y CVE-2026-106555, relacionadas con la conservación indebida de credenciales y estados de autenticación GSSAPI entre intentos; CVE-2026-106586, que afectaba a la aplicación de restricciones de authorized_keys sobre el establecimiento de túneles; y CVE-2026-106587, derivada de una interpretación incorrecta del valor «none» en determinadas opciones de configuración.

Aunque sus impactos y condiciones de explotación son diferentes, estos problemas comparten con el fallo de musl: la necesidad de interpretar correctamente los estados de autenticación, los valores de configuración y las restricciones de acceso. Ninguno de ellos implica por sí mismo el mismo bypass de contraseña corregido en OpenSSH 10.6p2.

Fuentes

-OpenSSH — notas oficiales de Portable OpenSSH 10.6p2.
OpenSSH Release Notes

-Alpine Linux — análisis técnico del bypass de autenticación.
Alpine Linux Security Advisory

-GitHub Advisory Database — CVE-2026-123158.
CVE-2026-123158