El 10 de noviembre de 2026, hora de Beijing, la Agencia de Seguridad Cibernética e Infraestructura de Estados Unidos (CISA) incluyó el fallo de omisión de autenticación de OpenSSH CVE-2026-123158 en su directorio de vulnerabilidades ya explotadas y estableció una fecha límite de 12 de noviembre para la mitigación, marcando además el elemento del directorio como requiriendo triaje forense. La empresa de seguridad Previdian informó que sus sensores registraron 20 intentos de explotación entre el 6 y el 8 de noviembre, involucrando 13 direcciones IP de atacantes, con distribución geográfica que abarcó 9 países. Estas dos actualizaciones desplazan el enfoque del informe de la vulnerabilidad hacia actividades de ataque reales, aunque los 20 intentos no equivalen a 20 intrusiones exitosas y los 9 países no representan necesariamente las ubicaciones de las víctimas.

Entrada excesivamente larga y coincidencia con valor de error

Alpine anunció que los atacantes deben poder conectarse al puerto SSH objetivo y conocer un nombre de cuenta cuyo campo de contraseña esté marcado con asteriscos. La máquina objetivo también debe tener al menos una cuenta local que utilice un hash de contraseña en formato $5$ o $6$. Una vez cumplidos estos requisitos, los atacantes pueden enviar contraseñas de entre 257 y 1024 bytes, sin necesidad de conocer la contraseña real de la cuenta objetivo para pasar por la autenticación; esta descripción no aplica a cuentas normales con hashes de contraseña válidos. Alpine indicó que en entornos compatibles, basta con una sola conexión, sin depender de reintentos continuos.

La causa técnica se encuentra en la intersección del procesamiento de contraseñas entre sshd y musl. Sin PAM, sshd invoca la función crypt() de la biblioteca C para calcular la entrada y compararla con el campo almacenado; cuando la entrada excede los 256 bytes, crypt() de musl devuelve un asterisco como valor de error. Las cuentas sin contraseña o que solo utilizan claves también pueden tener asteriscos en el archivo shadow, y al coincidir los caracteres, se interpreta erróneamente como autenticación exitosa. OpenSSH atribuye la causa raíz fuera de sshd, pero reconoce que puede ser explotada desde la ruta de sshd y evadida dentro de ella. Alpine explicó que sshd también puede tomar el valor de sal de otra cuenta para completar esta comparación, y que la corrección impide que los valores de error sean interpretados como autenticación exitosa.

Condición de activación y exclusiones

No basta con simplemente instalar Alpine para desencadenar el problema. Las condiciones listadas por Alpine incluyen que PasswordAuthentication permanezca en yes, que openssh-server no utilice PAM o que openssh-server-pam tenga UsePAM en no, que al menos un campo de contraseña de cuenta con inicio de sesión sea un asterisco, y que otra cuenta local posea un hash $5$ o $6$. La imagen tiny-cloud oficial sigue siendo segura en su primera ejecución, pero después de que un administrador configure una contraseña para la consola o agregue contraseñas hash mediante datos de usuario, podría cumplirse la combinación de condiciones. La cuenta alpine tiene permisos doas sin contraseña, por lo que una vez iniciada sesión se puede obtener acceso root.

Alpine excluye explícitamente varios escenarios comunes: no ejecutar sshd dentro de contenedores, configurar explícitamente PasswordAuthentication en no, tener openssh-server-pam con UsePAM en yes, cuentas bloqueadas con signo de exclamación, sistemas sin hashes de contraseña con formato de signo de dólar, e imágenes cloud donde la autenticación por contraseña esté deshabilitada por cloud-init. Los sistemas basados en glibc como Debian, Ubuntu y Fedora no están incluidos en esta ruta musl, por lo que no se puede generalizar este descubrimiento a todos los dispositivos Linux que puedan ser accedidos directamente. La cuenta root también está protegida por defecto por OpenSSH con PermitRootLogin prohibit-password, salvo que el administrador la cambie explícitamente a yes.

Versión de corrección y mitigación de emergencia

OpenSSH 10.6p2 fue lanzado el 5 de noviembre. Alpine publicó paquetes de corrección para las versiones 3.16 a 3.24 y edge, donde 3.24 se fija en 10.3_p1-r2, y edge se fija en 10.6_p2-r0; cada rama estable utiliza su propia versión de parche de reversión. Alpine requiere ejecutar la actualización antes de reiniciar sshd, y especifica que las imágenes desde 3.21.10, 3.22.8, 3.23.8, 3.24.4 en adelante incluyen la corrección. Las instancias en ejecución de versiones anteriores deben actualizarse o deshabilitar manualmente la autenticación por contraseña. También existen paquetes de reversión para las ramas 3.20 y anteriores, aunque algunas versiones ya han dejado de recibir soporte regular.

Cuando no sea posible actualizar inmediatamente, Alpine sugiere verificar primero que el inicio de sesión con clave funcione correctamente, luego establecer PasswordAuthentication en no, revisar la configuración e iniciar sshd nuevamente. Los administradores también pueden buscar en los registros del sistema cuentas que no deberían aceptar inicio de sesión por contraseña y que tienen registros de Accepted password, además de revisar el uso de doas, creación de usuarios, archivos y claves de autorización. El comunicado oficial indica que cuando no se pueda descartar un inicio de sesión anormal, la máquina debe tratarse como posiblemente comprometida; esta recomendación inicial solo define el alcance del diagnóstico, mientras que el estado actual de explotación se determinará según los materiales de CISA y Previdian proporcionados posteriormente. El comunicado también incluye los comandos sshd -t y sshd -T para verificar la configuración y el estado de autenticación por contraseña.

Estado de explotación conocida y límites de la observación

CISA en la fecha 9 de noviembre incluyó esta vulnerabilidad en el directorio Known Exploited Vulnerabilities, indicando que la institución ha obtenido evidencia de que ha sido utilizada en ataques reales, aunque el directorio no proporciona información sobre la identidad del atacante, el número de víctimas o la escala de la actividad. El artículo establece una fecha límite de resolución para el 12 de noviembre, exigiendo que se implementen medidas de mitigación según las indicaciones del fabricante, y que se evalúe la exposición a Internet bajo la guía aplicable BOD 26-04; si no hay medidas de mitigación disponibles, se debe dejar de usar el producto afectado según las directrices pertinentes. El artículo también marca la necesidad de forensic triage, es decir, priorización forense, y clasifica la actividad de ransomware conocida como Unknown, sin poder ser modificada a confirmada ausencia de uso de ransomware.

La página pública de sensores de Previdian indica que se observaron 20 intentos entre los días 6 y 8 de noviembre, provenientes de 13 direcciones IP diferentes de atacantes, con la distribución geográfica de estas IPs cubriendo a 9 países. La empresa define estos registros como intentos de explotación y distingue claramente entre intentos y éxito, por lo que estos números no pueden ser interpretados como 20 dispositivos comprometidos, 13 atacantes o 9 países víctimas; el artículo del directorio de CISA tampoco proporciona un conjunto de números para la escala de la actividad. El flujo de información autorizado por Ars Technica publicó un nuevo título, breve resumen, fecha y enlace el 9 de noviembre, titulando que la vulnerabilidad está siendo explotada; las condiciones de impacto técnico, versiones de corrección y pasos de mitigación siguen basándose en los materiales públicos de OpenSSH, Alpine y CISA.