sshole (CVE-2026-123158): revise su red

La CVE-2026-123158, apodada «sshole» (también escrita sshhole), permite iniciar sesión por SSH con una contraseña muy larga en sistemas Linux en los que el sshd de OpenSSH está compilado con musl libc sin PAM; el ejemplo más conocido es Alpine Linux. Está corregida en OpenSSH 10.6p2, publicada el 5 de noviembre de 2026, y desactivar la autenticación por contraseña la cierra hasta que pueda actualizar. La mayoría de las distribuciones de servidor habituales usan glibc y PAM y quedan fuera de la configuración afectada; el riesgo se concentra en equipos con Alpine, contenedores basados en Alpine que ejecutan sshd e imágenes de Linux embebido.

A quién afecta y a quién no

El registro CVE lo describe así: sshd en OpenSSH anterior a 10.6p2, en Linux, cuando se usa musl libc sin PAM, carece de una solución para una omisión de la autenticación por contraseña; en algunas configuraciones de cuentas funciona cualquier contraseña de entre 256 y 1024 caracteres. El registro le asigna 8,1 (alta) en CVSS 3.1.

El mecanismo, tal como lo describen Alpine y varios investigadores de seguridad: sin PAM, sshd comprueba una contraseña llamando a la función crypt() de la biblioteca C y comparando el resultado con la entrada de la cuenta en /etc/shadow. Con una entrada demasiado larga, crypt() de musl falla y devuelve la cadena *. Las cuentas que no deben iniciar sesión con contraseña suelen tener exactamente * como entrada en shadow, así que el valor de error coincide y sshd acepta el inicio de sesión. Una cuenta con un hash de contraseña real no se abre de este modo: el valor de error no coincide con el hash.

• Configuración afectada: OpenSSH anterior a 10.6p2, musl libc, sin PAM, autenticación por contraseña activada y al menos una cuenta cuya entrada en shadow es un simple *. La compilación de OpenSSH por defecto de Alpine no tiene PAM. Los investigadores citan entre las cuentas expuestas a los usuarios que solo entran con clave y al usuario por defecto de las imágenes cloud de Alpine; root también tiene * por defecto en Alpine, pero el valor por defecto PermitRootLogin prohibit-password rechaza el inicio de sesión de root con contraseña.
• Fuera de ella, según el registro CVE: las distribuciones basadas en glibc y las compilaciones de sshd que usan PAM. Dropbear, el servidor SSH que OpenWrt incluye por defecto, es un programa distinto de OpenSSH y no es el producto que nombra el registro; un dispositivo OpenWrt solo entra en juego si se le instaló el servidor de OpenSSH.
• Explotación: hay código de prueba de concepto público. La empresa de inteligencia de amenazas Previdian informa de que sus sensores observaron intentos de explotación; a 6 de noviembre de 2026, otras fuentes, como Safe Security, indicaban que la explotación real no estaba confirmada y que la CISA no había añadido la CVE a su catálogo Known Exploited Vulnerabilities. En cualquier caso, trate como urgente todo equipo afectado que acepte contraseñas SSH desde internet.

Una revisión de 10 minutos para administradores

Analice solo redes que sean suyas o que esté autorizado a probar.

Paso 1: localice los servicios SSH

Desde un equipo dentro de la red, liste todo lo que responde en el puerto 22, con la versión de software que anuncia. Sustituya el rango de ejemplo por sus propias subredes:

nmap -p 22 --open -sV 192.0.2.0/24

Incluya los hosts de contenedores y las redes de laboratorio. Un sshd dentro de un contenedor puede estar publicado en otro puerto, así que revise también los mapeos de puertos que expone su plataforma de contenedores.

Paso 2: compruebe en cada equipo la versión de OpenSSH y la biblioteca C

ssh -V muestra la versión de OpenSSH instalada. ldd --version muestra musl libc en un sistema con musl y la versión de glibc en uno con glibc. En Alpine, apk info -v | grep openssh muestra las versiones exactas de los paquetes.

ssh -V
ldd --version 2>&1 | head -1

Paso 3: compruebe si el inicio de sesión con contraseña está activo

Como root, muestre la configuración con la que sshd funciona realmente. passwordauthentication no significa que esta vía está cerrada en ese equipo.

sshd -T | grep -i passwordauthentication

Paso 4: liste las cuentas con un simple *

Son las cuentas que la omisión puede abrir:

awk -F: '$2 == "*" { print $1 }' /etc/shadow

Un equipo está expuesto si se cumplen las cuatro condiciones: versión de OpenSSH afectada, musl, autenticación por contraseña activada y al menos una de las cuentas listadas a la que SSH permite iniciar sesión.

La corrección

1. Actualice OpenSSH a 10.6p2, o al paquete corregido de su distribución. En Alpine, la instrucción publicada es apk upgrade -U -a.
2. Reinicie sshd. El demonio en ejecución mantiene el código antiguo hasta que se reinicia; en Alpine, rc-service sshd restart.
3. Hasta que pueda actualizar, configure PasswordAuthentication no en sshd_config y recargue sshd. Si sus usuarios ya entran con clave, para ellos no cambia nada; es la medida provisional que recomiendan los avisos.
4. Reconstruya las imágenes de contenedores que ejecutan sshd sobre una base Alpine y vuelva a desplegarlas: parchear el equipo no parchea la imagen.
5. Revise los inicios de sesión SSH recientes en los equipos afectados, sobre todo los inicios de sesión con contraseña correctos en cuentas que normalmente usan claves o nunca inician sesión.

Qué ve la monitorización de red y qué no

SSH va cifrado, así que la contraseña nunca cruza la red de forma legible. Un sensor de red no ve la contraseña, no sabe cuánto mide y no puede decir que se usó precisamente esta vulnerabilidad: esa prueba está en los registros del propio equipo.

Lo que sí ve la monitorización de red es el comportamiento alrededor de una intrusión. NetSenX evalúa cómo se comporta cada equipo en la red y señala escaneos, movimiento lateral, beaconing C2 y volúmenes inusuales de datos salientes, en todos los planes, también el Free. Un equipo que de repente acepta sesiones SSH desde orígenes con los que nunca se había comunicado, o un contenedor Alpine que tras un inicio de sesión empieza a conectarse a otros equipos internos, es justo el tipo de cambio para el que existen esas detecciones. Cada alerta explica en lenguaje claro por qué se activó. Úsela junto con las comprobaciones en los equipos descritas arriba, no en su lugar.

Si no está seguro de que nadie esté ya dentro, Cómo saber si hay alguien dentro de su red repasa las señales y las comprobaciones gratuitas, Cómo detectar el movimiento lateral y el beaconing C2 relaciona con MITRE ATT&CK lo que sigue a un inicio de sesión, y NDR, EDR o SIEM explica qué ve cada herramienta. El plan Free supervisa hasta 3 dispositivos sin límite de tiempo; consulte los precios.

Preguntas frecuentes

Fuentes

Todas consultadas el 6 de noviembre de 2026.

• CVE-2026-123158, registro CVE (cvelistV5) — descripción, versiones afectadas, puntuación CVSS 3.1 de 8,1, publicado el 5 de noviembre de 2026
• Alpine Linux — OpenSSH password authentication bypass — el aviso de la distribución
• OpenSSH release notes, 10.6p2
• OX Security — OpenSSH password authentication bypass on Alpine Linux — mecanismo y cuentas expuestas
• Previdian — CVE-2026-123158 exploitation attempts observed
• Safe Security — SSHole: high-severity OpenSSH vulnerability — estado de la explotación a 6 de noviembre de 2026

Escrito por el equipo de NetSenX en TriStiX S.L. Este artículo es información general basada en las fuentes públicas anteriores a 6 de noviembre de 2026; compruebe en el aviso de su distribución las versiones de paquete que le corresponden. Preguntas: info@netsenx.com.