Santo Domingo.- Fallo de OpenSSH en Alpine Linux dejó de ser teoría el pasado jueves.
Una contraseña inventada, con entre 257 y 1.024 caracteres, entra en cuentas que debían rechazar cualquier intento con contraseña.
El proyecto OpenSSH respondió el mismo día con la versión 10.6p2 y un aviso sin rodeos: quien opere un sistema Linux con la biblioteca musl y sin PAM (siglas en inglés de módulos de autenticación conectables) debe poner PasswordAuthentication en no o apagar el servicio SSH de inmediato.
El hallazgo lleva apodo propio, sshhole, y lo reportó Özgün Kültekin, investigador de Wakefield.
Kültekin contó que lo destapó con agentes de inteligencia artificial que corrigieron 17 mil 600 pruebas de autenticación con configuraciones distintas de OpenSSH, campos de contraseña deformados y claves de tamaño exagerado.
Solo una combinación aceptó lo inaceptable: OpenSSH sobre musl, sin PAM de por medio.
Damien Miller, mantenedor de OpenSSH, explicó la prisa con un dato incómodo.
El equipo supo del problema el 4 de noviembre y publicó la corrección al día siguiente porque ya vio casos de fallos descubiertos por herramientas de IA y redescubiertos por otra persona en cuestión de horas.
Esperar semanas con el fallo en silencio, escribió el proyecto en sus notas, termina favoreciendo a quien ataca.
La vulnerabilidad recibió por la tarde el código CVE-2026-123158, con puntuación 8,1 sobre 10, y hasta el momento de publicar esta nota nadie había reportado explotación en servidores reales.
Un asterisco en dos lugares a la vez
Todo nace de una coincidencia de un solo carácter.
En el archivo /etc/shadow, donde Linux guarda las contraseñas cifradas, muchas cuentas llevan un asterisco en el campo de la clave.
Ese asterisco significa esto: esta cuenta no entra con contraseña, punto. Así quedan los usuarios que solo acceden con llave SSH, las cuentas de despliegue y el usuario root en Alpine desde la versión 3.16.
OpenSSH carga una parte de la historia.
En 2016, para tapar la filtración de nombres de usuario por tiempos de respuesta (CVE-2016-6210), el servidor empezó a cifrar también los intentos contra cuentas sin clave usable, tomando prestada la sal de otra cuenta. La sal es el valor aleatorio que acompaña a cada cifrado.
La biblioteca musl aporta la otra mitad: su función crypt() devuelve un asterisco cuando el cifrado falla, y falla con las contraseñas de más de 256 caracteres en su ruta SHA-512.
La comparación cierra el círculo.
El intento largo produce un asterisco, el campo guardado también es un asterisco, y el servidor entiende que coinciden. BleepingComputer detalló que el fallo no rompe las cuentas con clave real: solo abre las que tienen el asterisco, justo las que nadie vigila porque se daban por cerradas.
Alpine ya vivió un susto parecido por otra vía con el CVE-2026-97229 de GitLab contra Alpine Linux, y esta vez el hueco está en la puerta de entrada del propio sistema.
El caso más serio vive en la nube. Las imágenes oficiales de Alpine para AWS y Azure traen un usuario llamado alpine con el campo en asterisco y permiso para volverse root con doas sin contraseña.
Si esa máquina acepta conexiones SSH con contraseña y corre el paquete openssh-server de siempre, un desconocido con una clave larguísima puede terminar con control total en un solo intento, sin fuerza bruta.
Quién queda expuesto y quién respira tranquilo
La exposición exige una combinación precisa: un sistema basado en musl (Alpine, OpenWrt, Buildroot o Yocto), OpenSSH sin PAM o con UsePAM en no, la autenticación con contraseña activa y otra cuenta local con una clave cifrada válida que preste su sal. Los contenedores solo corren riesgo si dentro de ellos vive un servidor SSH; una imagen Alpine de una aplicación común, sin ese servicio, no tiene por dónde recibir el intento.
Fuera del mapa quedan Debian, Ubuntu y Fedora, que usan la biblioteca glibc, y cualquier instalación donde PAM revise las contraseñas.
Dropbear, el servidor ligero que OpenWrt trae de fábrica, tampoco carga el fallo. Root conserva una protección extra de fábrica, PermitRootLogin prohibit-password, que bloquea su entrada con contraseña salvo que alguien la haya cambiado a mano.
La corrección tiene una trampa de lectura. Alpine no subió sus ramas estables a 10.6p2: parcheó la versión de cada rama y cambió la revisión del paquete, con paquetes corregidos hasta la rama 3.16, ya fuera de soporte. Buscar el número 10.6p2 en un Alpine puede dar una falsa calma.
El paquete actualizado manda, y tras instalarlo con apk upgrade openssh hay que reiniciar el servicio, porque actualizar el paquete no reemplaza al demonio que ya está escuchando.
Quien no pueda actualizar hoy tiene tarea corta: dejar PasswordAuthentication en no, reiniciar SSH y, de paso, revisar el registro.
En Alpine, el comando grep «Accepted password» sobre /var/log/messages muestra cada entrada aceptada con contraseña.
Si aparece una cuenta cuyo campo en /etc/shadow es un asterisco, esa entrada nunca debió existir y la máquina se trata como comprometida.
OpenSSH admite en sus notas que la raíz del problema vive fuera de su servidor, pero el parche salió de su casa en menos de un día.
Para miles de servidores pequeños, bastiones olvidados y equipos de red que corren Alpine sin que nadie recuerde su versión, la revisión pendiente es concreta: paquete al día, servicio reiniciado y un vistazo al registro antes de que una clave de 300 caracteres toque la puerta.
Por Henry Ramírez