Un fallo de OpenSSH permite, en determinadas configuraciones, conectarse a un servidor Linux sin conocer la contraseña, en un solo intento. El CERT-FR emitió el 5 de noviembre una alerta (CERTFR-2026-ALE-015), actualizada el 6 de noviembre con el identificador CVE-2026-123158. Los sistemas Alpine Linux, distribución basada en musl, son los principales afectados; la corrección obliga a reiniciar el servicio SSH.
Una conexión sin contraseña, bajo ciertas condiciones
La vulnerabilidad afecta a las versiones de OpenSSH anteriores a la 10.6p2, pero solo en sistemas Linux que utilizan la biblioteca C musl y cuyo demonio SSH funciona sin PAM, el módulo de autenticación habitual. Según el CERT-FR, un atacante puede entonces abrir una sesión enviando dos contraseñas sucesivas, la segunda de más de 256 y menos de 1.024 caracteres. La agencia gubernamental califica la explotación de «trivial» cuando se cumplen estas condiciones. Su alerta no menciona ataques constatados.
El boletín de Alpine Linux, publicado el mismo día, detalla la lista completa de condiciones. Es necesario que el paquete openssh-server esté compilado sin PAM (o que la variante con PAM esté configurada con UsePAM no), que la autenticación por contraseña esté activada, que es la configuración por defecto de OpenSSH, que al menos una cuenta tenga como contraseña el marcador «*» y que al menos una cuenta local tenga una contraseña con hash en formato $5$ o $6$.
El origen: un código de error confundido con una contraseña
El mecanismo, detallado por Alpine, se debe a una desafortunada coincidencia. Sin PAM, sshd verifica una contraseña aplicándole un hash con la función crypt() y comparando después el resultado con el valor almacenado. Para las cuentas cuyo valor almacenado es demasiado corto para contener una sal, el programa toma prestada la de otra cuenta. Ahora bien, en musl, crypt() devuelve «*» para señalar un error cuando la clave supera los 256 bytes. Como «*» es precisamente el valor registrado para las cuentas sin contraseña, la comparación tiene éxito y la puerta se abre.
Los mantenedores de OpenSSH consideran, en las notas de la versión 10.6p2 publicadas el 5 de noviembre, que la causa de fondo está fuera de sshd; no obstante, han integrado una solución alternativa que cierra esta vía de explotación. El fallo fue notificado por Özgün Kültekin, de la empresa Wakefield, y corregido por Damien Miller y Darren Tucker.
Quién está expuesto
Alpine indica que todas sus versiones comprobadas están afectadas, de la 3.21 a la 3.24, así como la rama edge, pero también versiones más antiguas, de la 3.16 a la 3.20. Se han publicado paquetes corregidos hasta la 3.16, incluida la 3.21, cuyo soporte terminó el 1 de noviembre. La cuenta root, entregada con una contraseña «*» desde aproximadamente la versión 3.16, solo es accesible si PermitRootLogin yes está activado, pero basta con otra cuenta capaz de convertirse en administrador.
Un caso merece especial atención: las imágenes cloud «tiny-cloud» de Alpine, de la 3.18.11 a la 3.24.3, incluyen un usuario alpine sin contraseña y autorizado a usar doas sin introducirla. Seguras en el primer arranque, se vuelven vulnerables en cuanto aparece un hash $6$ en la máquina, por ejemplo cuando un administrador define una contraseña de consola.
Según Alpine, no están afectados: los contenedores que no ejecutan sshd, los sistemas en los que la autenticación por contraseña está desactivada, la variante con PAM activado, las cuentas bloqueadas con «!» y las imágenes cloud-init configuradas sin contraseña.
Qué deben hacer los administradores
- Actualizar y después reiniciar sshd. El CERT-FR insiste: instalar el paquete no sustituye al demonio ya cargado en memoria. En Alpine, las versiones corregidas son, entre otras, la 10.3_p1-r2 para la 3.24 y la 10.2_p1-r1 para la 3.23, y las ediciones puntuales 3.21.10, 3.22.8, 3.23.8 y 3.24.4 incluyen la corrección.
- En su defecto, desactivar la autenticación por contraseña tras comprobar que la conexión por clave funciona, manteniendo una sesión abierta. Si ni siquiera eso es posible, el CERT-FR recomienda desactivar el servicio SSH.
- Buscar indicios de intrusión. Se trata de localizar en los registros conexiones aceptadas por contraseña en cuentas que no la tienen y, después, controlar el uso de doas, las cuentas creadas recientemente y las claves autorizadas. Alpine aconseja considerar la máquina comprometida si no puede descartarse una conexión sospechosa.
Para una empresa, la dificultad principal es el inventario: los servidores Alpine suelen esconderse en máquinas virtuales olvidadas, appliances o imágenes cloud desplegadas en serie. Ese ángulo muerto es lo primero que hay que abordar.
Preguntas frecuentes
¿Mi servidor Debian o Ubuntu está afectado por CVE-2026-123158?
Las condiciones descritas por el CERT-FR se refieren a sistemas Linux basados en la biblioteca musl con PAM desactivado. Un servidor que no reúna estas condiciones queda fuera del alcance de la alerta, pero sigue siendo recomendable actualizar OpenSSH.
¿Son vulnerables los contenedores Docker basados en Alpine?
Solo si ejecutan un servidor SSH. Según Alpine, un contenedor que no lanza sshd no está expuesto.
¿Hay que reiniciar después de la actualización?
Sí. El CERT-FR y Alpine recuerdan que actualizar el paquete no basta: hay que reiniciar el servicio sshd para que la versión corregida esté realmente en funcionamiento.
Fuentes
- [MàJ] Vulnérabilité dans OpenSSH (CERTFR-2026-ALE-015) — CERT-FR, 2026-11-06
- Security advisory: openssh-server password authentication bypass — Alpine Linux, 2026-11-05
- OpenSSH 10.6p2 (release-10.6p2) — OpenSSH, 2026-11-05