El escenario de pesadilla perfecto para un servidor Linux es cuando todo lo que un atacante necesita es alcanzar el puerto de Secure Shell (SSH) del servidor, entrar como Pedro por su casa y tomar el control. Eso es lo que le ocurrió a Alpine Linux, la popular distribución ligera de Linux para servidores. Para colmo de males, esto sucedió solo unos días después de que Alpine Linux esquivara por poco una bala del tamaño de un agujero de seguridad en su implementación de GitLab.

Como explicó el ingeniero de seguridad Gregory Bryant en su publicación de LinkedIn: "La mayoría de los bypass de autenticación provienen de cadenas lógicas complejas, pero la vulnerabilidad de OpenSSH de Alpine Linux de ayer (CVE-2026-123158) se reduce a un solo carácter: *".

Si ejecutas Alpine Linux (u otra distribución basada en musl) con el paquete openssh-server predeterminado (sin Módulos de Autenticación Conectables, o PAM) y la autenticación por contraseña habilitada, un atacante puede iniciar sesión en cuentas con contraseña deshabilitada, o solo con clave, simplemente enviando una contraseña de entre 257 y 1024 bytes de longitud.

Alpine Linux no es el único sistema operativo que usa musl, una versión ligera de la biblioteca estándar de C (libc). Otros sistemas operativos que usan musl y son potencialmente vulnerables incluyen Adélie Linux; Void Linux; Sabotage Linux; OpenWrt, una variante de Android; y el Proyecto Yocto, que se utiliza para construir distribuciones Linux embebidas.

Wind River, que produce la distribución comercial de Linux embebido Wind River Linux, también está investigando el problema. Un representante de la compañía me dijo: "Wind River se toma la seguridad en serio. Estamos revisando activamente la vulnerabilidad reportada y evaluando su impacto potencial. Tomaremos las medidas apropiadas según sea necesario".

Entre bastidores, cuando OpenSSH se compila sin PAM, verifica las contraseñas hasheando el intento de contraseña usando la función crypt() de la biblioteca C. Luego compara el resultado con el campo de contraseña almacenado de la cuenta. Hasta aquí, todo bien.

Pero cuando una clave tiene más de 256 bytes, la función crypt() de musl devuelve la cadena * como indicador de error. Eso es también lo que contiene el campo de contraseña para cualquier cuenta sin contraseña, como una cuenta solo con clave. Por lo tanto, el "hash" coincide y el inicio de sesión tiene éxito, y el atacante entra.

Para explotarlo, un atacante solo necesita el nombre de dicha cuenta. El atacante también necesita al menos otra cuenta en la máquina con un hash de contraseña de 5 o 6, y luego enviar una contraseña de 257 a 1024 bytes. Según Alpine, un solo usuario con contraseña es suficiente para hacer accesibles todas las cuentas sin contraseña.

En los sistemas Linux que usan crypt() de glibc, que son casi todos, el mismo intento devolvería NULL en caso de error, lo que sshd ya rechaza, por lo que Debian, Ubuntu, Fedora, etc., no se ven afectados.

Según *sshole, el grupo que descubrió el problema, este es un efecto secundario que ha estado oculto desde 2016.

Alpine dijo que todas las versiones que verificó están afectadas: 3.21 a 3.24, edge, y las ramas más antiguas 3.16 a 3.20. La exposición requiere lo siguiente:

Root no está directamente expuesto en la mayoría de los casos. Se ha distribuido como root:* en la imagen base desde aproximadamente Alpine 3.16, pero la configuración predeterminada PermitRootLogin prohibit-password de OpenSSH lo bloquea. Otra cuenta que pueda convertirse en root, por ejemplo mediante doas, todavía le da al atacante una ruta a root.

Alpine señaló sus imágenes oficiales tiny-cloud, versiones 3.18.11 a 3.24.3, como especialmente vulnerables. Estas vienen con un usuario alpine con un campo de contraseña * y doas sin contraseña. Son seguras en el primer arranque pero se vuelven explotables una vez que existe cualquier hash 6 en la máquina. Eso puede suceder cuando un administrador establece una contraseña de consola o cuando los datos de usuario agregan un usuario con una contraseña hasheada, lo que significa, esencialmente, todas ellas.

Alpine lanzó 3.21.10, 3.22.8, 3.23.8 y 3.24.4 el jueves, con la corrección de OpenSSH entre los cambios de seguridad. También publicó paquetes corregidos para cada versión hasta la 3.16. Alpine 3.21 alcanzó el fin de soporte el 1 de noviembre.

El recién lanzado OpenSSH 10.6p2 evita el problema en sshd. Las ramas estables de Alpine llevan un parche para el mismo problema. Deberías ejecutar apk upgrade -U -a y luego reiniciar el