OpenSSH en Alpine Linux (y otros sistemas basados en musl libc) · Omisión de autenticación por contraseña vía SSH

Una contraseña absurdamente larga abriendo una puerta cerrada: esa es, resumida, la paradoja de CVE-2026-123158. El 5 de noviembre de 2026, el proyecto Alpine Linux —una distribución de Linux muy usada en contenedores e imágenes de nube por su tamaño reducido— avisó de que, bajo una combinación concreta de ajustes, el servidor OpenSSH (el programa que da acceso remoto cifrado a un sistema a través del protocolo SSH) podía aceptar el inicio de sesión en cuentas que, en teoría, no tienen contraseña. No es un agujero de los que comprometen a «todo el mundo», pero quien reúna esas condiciones debe actuar sin demora.

Descripción

Qué es. CVE-2026-123158, bautizada por su descubridor como «sshole», es una omisión de autenticación (authentication bypass): un fallo que permite superar el control de acceso sin presentar credenciales válidas. En este caso, un atacante con acceso de red al puerto SSH (por defecto el 22) puede iniciar sesión en cuentas sin contraseña establecida. El identificador CVE (Common Vulnerabilities and Exposures) es el código estándar con el que se cataloga internacionalmente cada vulnerabilidad. La debilidad subyacente se clasifica como CWE-394 («valor de retorno o código de estado inesperado»): el programa interpreta mal lo que una función del sistema le devuelve.

A quién afecta. El problema no está en el código de OpenSSH como tal, sino en su combinación con musl libc, la biblioteca de funciones básicas del sistema que usa Alpine (en lugar de la más habitual glibc). Por eso afecta de forma específica a Alpine Linux y a otros sistemas basados en musl (por ejemplo, imágenes de OpenWrt o Buildroot). Distribuciones como Debian, Ubuntu, Fedora o RHEL no están afectadas. Un sistema es vulnerable únicamente si se dan todas estas condiciones a la vez:

• El servidor ejecuta openssh-server compilado sin PAM (el subsistema de autenticación modular de Linux), o bien openssh-server-pam con la opción UsePAM no. Con UsePAM yes no es explotable.
• La autenticación por contraseña está activada (PasswordAuthentication yes, que es el valor por defecto de OpenSSH).
• Existe al menos una cuenta cuyo campo de contraseña en /etc/shadow es exactamente un asterisco (*), que significa «sin contraseña utilizable». Son ejemplos la cuenta root (que en Alpine lleva root:* desde ~3.16, aunque la protege el ajuste por defecto PermitRootLogin prohibit-password), usuarios creados solo para acceso por clave, o el usuario alpine de las imágenes de nube.
• Existe además otra cuenta local con una contraseña «real» almacenada como hash de tipo $5$ (SHA-256) o $6$ (SHA-512).

Versiones afectadas. Según Alpine, están afectadas todas las ramas revisadas, de la 3.16 a la 3.24 y edge, con los paquetes de OpenSSH anteriores a los corregidos (ver apartado de parches). Cuentan con un riesgo especial las imágenes oficiales de nube de Alpine (tiny-cloud, de la 3.18.11 a la 3.24.3): su usuario alpine lleva contraseña * y doas (equivalente a sudo) sin contraseña, de modo que un acceso no autorizado puede derivar en control total (root) del sistema.

Mecánica

Cómo funciona el fallo

Cuando OpenSSH valida una contraseña sin PAM, toma lo que teclea el usuario, lo cifra con la función crypt() del sistema y compara el resultado con el hash guardado en /etc/shadow. Un hash es la huella criptográfica de la contraseña: no se almacena la clave en claro, solo esa huella. La cadena de crypt() incluye una sal (salt), un valor que individualiza cada hash para que dos contraseñas iguales no produzcan la misma huella.

La cadena de fallos encadena tres hechos:

1. Para una cuenta cuyo campo es demasiado corto para contener una sal (el caso del simple *), OpenSSH toma «prestada» la sal de otra cuenta que sí tenga un hash real ($5$ o $6$).
2. En musl libc, cuando la contraseña recibida supera los 256 bytes, crypt() no devuelve un error nulo (como haría glibc, que OpenSSH ya rechaza), sino la cadena literal * como señal de error.
3. Pero * es, a la vez, el valor que marca «cuenta sin contraseña» en /etc/shadow. OpenSSH compara entonces * (lo «calculado») con * (lo almacenado), ve que coinciden y da por válido el acceso.

En la práctica, el atacante solo tiene que intentar iniciar sesión contra una de esas cuentas enviando una contraseña de entre 257 y 1.024 bytes. Según el investigador, el ataque es remoto, previo a la autenticación, no requiere credenciales ni reintentos y «funciona siempre». El resultado es acceso a la cuenta sin contraseña; y en las imágenes de nube, al combinarse con doas sin contraseña, escalada a root.

Respuesta del creador

Respuesta de los responsables y de las autoridades

Proyecto OpenSSH. El equipo de OpenSSH (OpenBSD) publicó la versión corregida 10.6p2 el 5 de noviembre de 2026. La corrección (commit 4353fdc, en auth-passwd.c) consiste en que sshd rechace cualquier hash almacenado de menos de cuatro caracteres, evitando así la confusión con el *. Según el investigador, Damien Miller (OpenSSH) indicó que el proyecto considera peligrosos los embargos largos, por lo que el parche se publicó sin un periodo de secreto prolongado.

Alpine Linux. Los mantenedores publicaron un aviso de seguridad el 5 de noviembre de 2026 y portaron la corrección a todas las ramas, incluidas versiones ya fuera de soporte (3.17 a 3.20). El aviso insiste en un matiz importante: «actualizar el paquete por sí solo no reemplaza el demonio en ejecución», de modo que hay que reiniciar sshd después de actualizar. Alpine agradece el análisis a Timo Teräs y el empaquetado a Natanael Copa.

Descubrimiento. El fallo fue reportado por el investigador Özgün Kültekin (de Wakefield). En el momento de redactar su aviso, Alpine señalaba que «no se había asignado identificador CVE»; posteriormente MITRE publicó CVE-2026-123158.

Autoridades. INCIBE-CERT (España) publicó el aviso INCIBE-2026-842 con importancia «Alta». La oficina federal alemana BSI también emitió una alerta. En el momento de redactar, la vulnerabilidad no figura en el catálogo KEV (Known Exploited Vulnerabilities) de la estadounidense CISA, que recoge los fallos con explotación confirmada. Ni Alpine ni OpenSSH informan de explotación real; existen, eso sí, laboratorios públicos de reproducción.

Parches y mitigaciones

Parches, mitigaciones y qué hacer ya

1. Actualizar (recomendado). En Alpine, actualizar el paquete openssh a la versión corregida de cada rama y reiniciar el servicio:

apk upgrade -U -a
rc-service sshd restart

Versiones corregidas del paquete openssh por rama (según Alpine e INCIBE-CERT):

• 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
• 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

En otros sistemas (no Alpine) basados en musl, actualizar a OpenSSH 10.6p2. Nota: Alpine mantiene la numeración «antigua» del paquete con el parche aplicado por detrás, por lo que algunos escáneres que solo miran el número de versión pueden marcar falsos positivos.

2. Si no puedes actualizar de inmediato (mitigación provisional). Asegúrate primero de poder entrar por clave SSH (sin depender de la contraseña), desactiva el acceso por contraseña y reinicia el servicio:

echo "PasswordAuthentication no" > /etc/ssh/sshd_config.d/00-no-passwords.conf
sshd -t && rc-service sshd restart
sshd -T | grep -i passwordauthentication

Mantén abierta una sesión existente mientras lo pruebas, para no quedarte fuera. Alternativamente, usar openssh-server-pam con UsePAM yes también neutraliza el fallo. Las imágenes creadas a partir de 3.21.10, 3.22.8, 3.23.8, 3.24.4 y posteriores ya incluyen la corrección.

3. Revisar si ya hubo acceso. Busca en /var/log/messages líneas Accepted password for correspondientes a cuentas que no deberían tener contraseña (alpine, root o usuarios solo-clave). Revisa el uso de doas, usuarios creados recientemente, ficheros modificados y claves en authorized_keys. Si no puedes descartar un inicio de sesión indebido, trata la máquina como comprometida.

Apunte legal (contexto UE/España). Si de esta vulnerabilidad se derivara un acceso no autorizado con afectación de datos personales, aplican las obligaciones del RGPD: notificación a la AEPD en un plazo máximo de 72 horas (art. 33) y, en su caso, comunicación a los afectados (art. 34). Las entidades sujetas a la Directiva NIS2 deben además atender sus propios deberes de notificación de incidentes.

Fuentes

• Alpine Linux — Security advisory: openssh-server password authentication bypass (05/11/2026)
• INCIBE-CERT — Omisión de autenticación por contraseña en OpenSSH de Alpine Linux (INCIBE-2026-842)
• Registro CVE-2026-123158 (CVE Program, cvelistV5)
• Ethiack — sshole (CVE-2026-123158): análisis técnico del descubrimiento
• OpenSSH — Release Notes (10.6p2)
• BleepingComputer — OpenSSH flaw lets attackers log into password-disabled Linux accounts
• LWN.net — Critical security vulnerability affects OpenSSH on Alpine Linux systems
• BSI — Cybersicherheitswarnung: OpenSSH (Alpine Linux)
• Detectify — Critical vulnerability: OpenSSH authentication bypass on Alpine Linux (CVE-2026-123158)