Un fallo de autenticación de OpenSSH puede permitir el acceso SSH no autorizado en determinados sistemas Linux que usan musl libc sin PAM. Se han observado intentos de explotación. Los administradores deben verificar su exposición, aplicar la corrección del proveedor y reiniciar el daemon de SSH.
El 5 de noviembre de 2026, OpenSSH publicó la versión 10.6p2 para corregir una omisión de la autenticación por contraseña (authentication bypass). El problema, registrado como CVE-2026-123158, puede permitir que un atacante acceda a ciertas cuentas sin conocer una contraseña válida. Alpine Linux es una distribución afectada especialmente importante porque su paquete estándar de servidor OpenSSH se compila sin PAM.
Alpine también se basa en musl, una biblioteca estándar de C compacta. Una biblioteca de C es el conjunto de funciones básicas en las que se apoyan los programas, incluida la que calcula el hash de las contraseñas. Las compilaciones de Red Hat usan otra biblioteca, glibc, un detalle que importa más adelante en este artículo.
Esto no es una vulneración universal de OpenSSH. Un sistema vulnerable debe cumplir varias condiciones de autenticación y de cuentas. Pero en los sistemas afectados, el acceso no autorizado a una cuenta puede convertirse en una vía hacia archivos sensibles o privilegios elevados.
Las notas de la versión de OpenSSH confirman la solución alternativa (workaround). El aviso de Alpine del 5 de noviembre identifica las configuraciones afectadas, los paquetes corregidos y las medidas de corrección necesarias.
La vulnerabilidad en resumen
| Dato | Lo que dicen las fuentes |
|---|---|
| Identificador | CVE-2026-123158 |
| Divulgación | 5 de noviembre de 2026 (la versión de OpenSSH y el aviso de Alpine, que indicaba que aún no se había asignado ningún identificador CVE) |
| Debilidad | Omisión de la autenticación por contraseña |
| Sistemas pertinentes | OpenSSH con musl libc y PAM desactivado, cuando además se dan las condiciones indicadas más abajo |
| Efecto potencial | Inicio de sesión no autorizado en una cuenta, posiblemente seguido de una escalada de privilegios cuando los permisos de la cuenta lo permiten |
| Corrección en origen (upstream) | Portable OpenSSH 10.6p2 |
| Actividad | Observaciones en honeypots compatibles con intentos de explotación, no una prueba de vulneración generalizada |
| Acción administrativa | Evaluar la configuración, actualizar los paquetes, reiniciar sshd (el programa servidor de SSH), examinar la actividad de autenticación sospechosa |
Las condiciones que hacen que un sistema esté afectado
Alpine identifica todas las condiciones siguientes en su configuración afectada:
- El servidor SSH usa la ruta de autenticación sin PAM. Esto incluye el paquete
openssh-serverde Alpine o su compilación compatible con PAM configurada conUsePAM no. PasswordAuthentication yespermite la ruta de inicio de sesión por contraseña correspondiente.- Una cuenta objetivo tiene
*en su campo de contraseña. Estas cuentas pueden estar pensadas para el acceso con claves SSH en lugar del inicio de sesión por contraseña. - Al menos otra cuenta local tiene un hash de contraseña
$5$(SHA-256) o$6$(SHA-512). - Un atacante puede llegar al servicio SSH y dispone de un nombre de cuenta objetivo utilizable.
PAM son las siglas de Pluggable Authentication Modules. Es un marco a través del cual las aplicaciones pueden usar los mecanismos de autenticación configurados. El comportamiento afectado se produce por una ruta distinta cuando PAM está desactivado.
Un sistema no está expuesto por esta vía concreta solo porque use Alpine o contenga la biblioteca musl. Los contenedores que no ejecutan sshd no están afectados como servidores SSH. Alpine incluye PasswordAuthentication no y un servidor con PAM habilitado mediante UsePAM yes entre las configuraciones no afectadas por este problema.
Según Red Hat, sus productos, incluido RHEL, no están afectados porque sus compilaciones de OpenSSH se enlazan con glibc y usan PAM de forma predeterminada. Fuente: aviso de Alpine y evaluación de CVE de Red Hat.
Cómo funciona la omisión
Linux suele almacenar un hash de contraseña, un valor derivado de una contraseña, en lugar de la contraseña original. Algunas cuentas no tienen, de forma intencionada, ningún hash de contraseña utilizable. Su campo de contraseña puede contener en su lugar un marcador especial, *, que no debería permitir un inicio de sesión por contraseña.
La función crypt() de la biblioteca musl también puede devolver * como indicación de error cuando recibe una contraseña inusualmente larga. En la ruta vulnerable de comprobación de contraseñas de OpenSSH sin PAM, ese resultado de error puede confundirse con una coincidencia con el marcador * almacenado en una cuenta. La presencia adicional de otra cuenta local que usa un hash de contraseña compatible forma parte de las condiciones notificadas.
El resultado es un fallo grave de un límite de confianza (trust boundary): un error de una biblioteca de nivel inferior puede tratarse como prueba de una autenticación correcta, aunque la cuenta no tenga una contraseña válida. Las notas de OpenSSH 10.6p2 indican que la causa de fondo está fuera de sshd, pero que el comportamiento inseguro puede evitarse ahí.
Esta vulnerabilidad ilustra una regla general de seguridad del software: un estado de error nunca debe interpretarse como una autorización o una autenticación correctas.
Observaciones de explotación y lo que demuestran
El 8 de noviembre, el SANS Internet Storm Center informó sobre actividad con contraseñas largas recogida por sus honeypots SSH Cowrie, servidores señuelo que registran lo que intentan los atacantes. Los recuentos que publicó fueron 58 el 4 de noviembre, 232 el 5 de noviembre, 713 el 6 de noviembre, 246 el 7 de noviembre y 51 hasta la actualización del informe del 8 de noviembre a las 15:44 UTC.
Se trata de observaciones de contraseñas largas, no de vulneraciones exitosas verificadas, ni siquiera de intentos dirigidos exclusivamente a esta CVE. SANS señala que parte de la actividad anterior no estaba relacionada. Identificó el 5 de noviembre como el primer uso reconocible del patrón específico de esta vulnerabilidad. El recuento parcial del 8 de noviembre no es directamente comparable con los días anteriores completos.
La observación basta para establecer que existe interés por parte de los atacantes y para justificar una acción defensiva rápida. No establece el volumen de explotación a escala mundial ni el número de sistemas de producción vulnerados.
Versiones con parche y mitigación inmediata
La corrección de seguridad en origen está en OpenSSH 10.6p2. Las distribuciones de Linux pueden retroportar esa corrección (backport), es decir, aplicarla a paquetes que llevan números de versión de origen anteriores.
Alpine publicó estas revisiones de paquete corregidas:
| Rama de Alpine | Paquete de OpenSSH corregido |
|---|---|
| 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 |
Otras ramas más antiguas figuran en la matriz completa de parches de Alpine. Comprueba el aviso real de la distribución y la revisión del paquete instalado en lugar de suponer que cualquier versión anterior a 10.6p2 carece de parche.
Para Alpine, su aviso indica esta secuencia de actualización y reinicio del servicio:
apk upgrade -U -a
rc-service sshd restartReiniciar el daemon en ejecución es imprescindible. Alpine advierte expresamente que actualizar un paquete no sustituye el proceso sshd que ya está en ejecución. Aplica los cambios mediante un proceso de mantenimiento autorizado, con una consola confirmada u otra vía de administración alternativa.
Si hay que retrasar la aplicación del parche, Alpine recomienda desactivar la autenticación SSH por contraseña configurando PasswordAuthentication no en la configuración efectiva de sshd. Antes de reiniciar o recargar el servicio, verifica el acceso con claves SSH y mantén abierta una sesión administrativa operativa para no quedarte sin acceso. Es una mitigación temporal, no un motivo para aplazar indefinidamente la actualización de seguridad.
Investigar un posible acceso no autorizado
Aplicar el parche bloquea la ruta vulnerable conocida a partir de ahora. No deshace ningún inicio de sesión no autorizado anterior.
En los sistemas que cumplían las condiciones de exposición, revisa los registros de autenticación SSH en busca de inicios de sesión por contraseña exitosos en cuentas pensadas para aceptar solo claves. Investiga también los cambios inexplicables en cuentas o en claves autorizadas, la actividad de elevación de privilegios y los cambios sospechosos en archivos. Un único evento inesperado en los registros (logs) merece una investigación, pero no es, por sí solo, una prueba de que se haya explotado esta CVE. Nuestro artículo sobre qué hacer después de una corrección ya explotada aplica el mismo principio a los dispositivos perimetrales (edge): una corrección no te dice quién entró antes de ella.
Alpine destaca un problema adicional en ciertas imágenes oficiales de tiny-cloud, las imágenes de máquinas virtuales en la nube de Alpine. Su cuenta alpine puede no tener una contraseña utilizable y, al mismo tiempo, tener privilegios de doas sin contraseña (doas es una herramienta que permite a un usuario ejecutar comandos como administrador). Esas imágenes no son necesariamente explotables en el primer arranque, pero la combinación afectada de estados de la cuenta y del hash de contraseña puede agravar el impacto.
Alpine indica que las imágenes compiladas a partir de 3.21.10, 3.22.8, 3.23.8 y 3.24.4 o posteriores incluyen el paquete corregido. Las instancias iniciadas desde imágenes anteriores siguen necesitando la actualización del paquete o el cambio en la configuración de contraseñas. Consulta las indicaciones de Alpine sobre impacto y detección.
Qué deben hacer ahora los administradores
Las organizaciones que operan Alpine u otros despliegues SSH pertinentes basados en musl pueden seguir cinco pasos:
- Determinar si se cumplen las condiciones documentadas.
- Aplicar el paquete corregido del proveedor.
- Reiniciar el daemon SSH real, es decir, el proceso en ejecución.
- Verificar la configuración de autenticación efectiva.
- Revisar los registros de autenticación cuando sea plausible una exposición previa.
No hay motivos para considerar comprometida toda instalación de OpenSSH. Tampoco hay motivos para suponer que una cuenta que solo usa claves SSH está protegida si el servidor sigue permitiendo una ruta vulnerable de autenticación por contraseña. Los equipos que no ejecutan ningún servidor SSH en Alpine ni en otro sistema musl no tienen que hacer nada respecto a este problema concreto y pueden tratarlo como un caso de estudio.
La prioridad inmediata es la evaluación específica de cada configuración, la aplicación del parche del proveedor y la verificación del servicio en ejecución.
Para profundizar
- Aviso de seguridad de Alpine Linux, 5 de noviembre de 2026: configuraciones afectadas, explicación técnica, versiones corregidas, corrección y detección.
- Notas de la versión 10.6p2 de OpenSSH portable, 5 de noviembre de 2026: solución alternativa en origen y límites técnicos.
- Evaluación de Red Hat sobre CVE-2026-123158: aplicabilidad específica de cada distribución.
- SANS ISC, 8 de noviembre de 2026: escaneos observados y límites probatorios.