OpenSSH CVE-2026-123158: ¿es vulnerable tu servidor?

El 5 de noviembre de 2026 salió Portable OpenSSH 10.6p2 con un arreglo de seguridad para un salto de la autenticación por contraseña. Lo cuentan las notas de versión de OpenSSH, el aviso de Alpine y la ficha de Ubuntu. La CISA lo añadió el 9 de noviembre a su catálogo de vulnerabilidades explotadas.

Esto no lo he podido probar en mi servidor como lo haría con un parche, porque mi servidor no es vulnerable. Lo Probado es del 12 de noviembre, en Ubuntu 24.04, y se limita a comprobar las condiciones. Lo demás es Revisado, no ejecutado (así distingo ambas cosas).

¿Qué falla y a quién afecta?

Según OpenSSH, el problema afecta a sistemas Linux que usan la libc musl con PAM desactivado, y su causa está fuera de sshd, aunque sshd puede esquivarla.

La ficha de Ubuntu lo resume así: en esa combinación, para algunas configuraciones de cuentas, sirve cualquier contraseña de entre 256 y 1024 caracteres. Alpine afina: de 257 a 1024 bytes.

An attacker who can reach your SSH port can log in without knowing any password.

Aviso de Alpine, 05/11/2026

El aviso de Alpine pide que se cumplan las cuatro condiciones a la vez:

• sshd sin PAM: el paquete openssh-server de Alpine, o openssh-server-pam con UsePAM no. Con UsePAM yes no está afectado.
• PasswordAuthentication yes.
• Una cuenta con * en el campo de contraseña, como root en la imagen base.
• Al menos otra cuenta con un hash $5$ o $6$.

Alpine lista como afectadas todas sus ramas revisadas, de la 3.21 a la 3.24 y edge, además de las sin soporte. Las versiones corregidas dependen de la rama, por ejemplo 10.3_p1-r2 en la 3.24 y 10.6_p2-r0 en edge. Después de actualizar, reinicia sshd: Alpine advierte de que el paquete no sustituye el demonio en marcha.

Sobre la explotación, The Hacker News recoge que Previdian vio el primer intento menos de nueve horas después de publicarse el CVE y confirmó root en un señuelo con Alpine. Es dato de esa firma. La CISA confirma que se explota. Aquí no hay pasos para reproducirlo.

¿Y Ubuntu, Debian o mi distribución?

Ubuntu da el CVE como «Not affected» desde la 14.04 hasta la 26.10. Según su equipo de seguridad, no usan musl por defecto y su OpenSSH enlaza con glibc y usa PAM. Lo he mirado en mi Ubuntu 24.04. De Debian y Red Hat no he revisado el estado.

Donde sí puede haber riesgo:

• Contenedores y sistemas mínimos con Alpine.
• Imágenes que alguien montó con musl y equipos embebidos.
• Si no sabes qué libc tienes, la comprobación de abajo te lo dice en un segundo.

¿Cómo compruebo si mi servidor cumple las condiciones?

Escribí un script de solo lectura que reúne las cuatro cosas. No cambia ficheros ni se conecta a nada. Necesita root solo para leer /etc/shadow, y acepta otra ruta como argumento para probarlo con un fichero de ejemplo.

#!/bin/bash
# Solo lectura. Uso: sshole-check.sh [fichero_shadow]
SH="${1:-/etc/shadow}"
SSHD=/usr/sbin/sshd
echo "== libc del sistema"
if ldd --version 2>&1 | grep -qi musl; then echo "musl"; else ldd --version 2>&1 | head -1; fi
echo "== bibliotecas de sshd"
ldd "$SSHD" 2>&1 | grep -Eo 'lib(c\.musl[^ ]*|c\.so\.6|pam\.so\.[0-9]+)' | sort -u
echo "== configuracion efectiva"
"$SSHD" -T 2>/dev/null | grep -Ei '^(usepam|passwordauthentication) '
echo "== cuentas en shadow"
awk -F: '$2=="*"{a++} $2 ~ /^\$(5|6)\$/{h++} END{printf "con \"*\": %d\ncon hash $5$ o $6$: %d\n", a, h}' "$SH"

Para validar la lógica del último bloque lo pasé por un shadow de ejemplo con cuatro cuentas (root:*, svc:*, ana con hash $6$ y bob:!). Dio 2 cuentas con * y 1 con hash $6$, lo esperado. Esa parte no demuestra nada sobre musl: solo que el contador cuenta bien.

Esto devolvió en mi Ubuntu 24.04, el 12 de noviembre, con la parte de las cuentas y la configuración de contraseñas recortada a propósito:

== libc del sistema
ldd (Ubuntu GLIBC 2.39) 2.39
== bibliotecas de sshd
libc.so.6
libpam.so.0
== configuracion efectiva
usepam yes
passwordauthentication (según tu configuración)
== cuentas en shadow
(contadores de cuentas omitidos)

¿Cómo lo leo?

Si sale musl y sshd no enlaza libpam, estás en el caso que describe Alpine; mira entonces las otras dos líneas. Mi servidor no cumple las condiciones: usa glibc y su sshd carga PAM. No publico los datos de mis cuentas ni mi configuración de SSH.

Un detalle sobre ese último contador: Ubuntu guarda hoy los hashes como yescrypt ($y$), así que en Ubuntu daría 0 aunque hubiera cuentas con contraseña. El criterio de $5$ y $6$ es el de Alpine. Cuenta para sistemas con musl, no para decidir si Ubuntu está en peligro.

¿Qué hago si sí cumplo las condiciones?

• Actualiza el paquete openssh a la versión corregida de tu rama y reinicia sshd.
• Mientras tanto, pon PasswordAuthentication no y reinicia sshd. Es la mitigación del aviso de Alpine. Comprueba antes, con otra sesión abierta, que entras con clave.
• Si usas imágenes tiny-cloud de Alpine (de la 3.18.11 a la 3.24.3), mira el usuario alpine con doas sin contraseña que el aviso menciona.

Lo que no he probado

No tengo una Alpine vulnerable, así que no he visto el fallo ni ejecutado ninguna explotación, ni he aplicado el parche.

Todo lo que cuento sobre musl, los límites de contraseña y las versiones corregidas sale del aviso de Alpine, de las notas de OpenSSH y de la ficha de Ubuntu. La fecha límite que algunos medios atribuyen a la CISA no figura en su página, y por eso no la doy.

Mi opinión

Un fallo que solo afecta a una combinación poco común acaba en el catálogo de explotadas, y por eso conviene mirar la configuración antes que el titular. La mayoría de servidores Ubuntu no tienen nada que hacer aquí.

Aun así, hay dos lecturas que te sirven en cualquier caso:

• Desactivar las contraseñas y entrar con clave cierra una de las condiciones sin esperar a ningún parche. Es parte del paso de asegurar SSH de mi checklist de seguridad inicial.
• Sobre el propio SSH escribí hace poco lo de la compresión que quita OpenSSH 10.6.

David Abellán