En seguridad informática, algunos de los peores fallos nacen de dos piezas que funcionan bien por separado y fallan cuando se juntan. Es lo que ha pasado con *sshole, una vulnerabilidad que se hizo pública el 5 de noviembre de 2026. En ciertas configuraciones de Alpine Linux, una distribución muy ligera y muy usada en contenedores y servidores en la nube, permitía iniciar sesión por SSH en cuentas que en teoría no aceptaban ninguna contraseña. Bastaba con escribir una contraseña desmesuradamente larga.

Según BleepingComputer, el fallo lo descubrió el investigador Özgün Kültekin, que publicó los detalles técnicos y explicó que lo encontró con la ayuda de agentes de IA que ejecutaron unas 17.600 pruebas de autenticación. Ese mismo día, Alpine publicó su aviso de seguridad y OpenSSH lanzó una versión corregida.

Cómo funciona por dentro: un asterisco que lo complica todo

En Linux, las contraseñas no se guardan tal cual. Se almacena un hash, una especie de huella matemática, en el archivo /etc/shadow. Cuando alguien intenta entrar, el sistema calcula la huella de lo que ha tecleado y la compara con la guardada. Si coinciden, se abre la puerta.

Hay cuentas que no deben aceptar contraseña: cuentas de servicio, cuentas que solo entran con clave criptográfica o cuentas bloqueadas. En su campo de contraseña suele haber un simple asterisco (*). Como ninguna huella real se parece a un asterisco, ninguna contraseña debería coincidir con él.

Aquí entra la segunda pieza. Alpine no usa glibc, la biblioteca estándar de C de la mayoría de distribuciones, sino musl, una alternativa más compacta. Cuando la función crypt() de musl, la que calcula esas huellas, no puede procesar una contraseña, no devuelve un error vacío: devuelve justamente un asterisco. Según Orca Security, musl se comporta así desde 2012. Además, sus algoritmos SHA-256 y SHA-512 rechazan contraseñas de más de 256 bytes.

Si se juntan ambas cosas, el resultado es este: el atacante envía una contraseña de entre 257 y 1.024 bytes, crypt() falla y devuelve *, el servidor SSH compara ese asterisco con el asterisco guardado en la cuenta bloqueada… y coinciden. Acceso concedido.

BleepingComputer añade otra pieza a la historia: un cambio que OpenSSH introdujo en 2016 para evitar que un atacante averiguase qué usuarios existían en un sistema (CVE-2016-6210). Desde entonces, el servidor calcula huellas incluso para cuentas sin contraseña utilizable. Era una medida de seguridad razonable, pero con musl acabó abriendo esta grieta.

Quién está afectado (y quién no)

No basta con tener Alpine. Según los análisis de Orca Security y Detectify, tienen que darse varias condiciones a la vez:

• El servidor SSH funciona sobre musl y sin PAM, el sistema de módulos de autenticación de Linux. El paquete de OpenSSH que Alpine instala por defecto no usa PAM.
• La autenticación por contraseña está activada, que es la opción por defecto.
• Hay al menos una cuenta con un asterisco en lugar de contraseña.
• Hay al menos otra cuenta local con una contraseña real.

Las versiones afectadas van de Alpine 3.16 a 3.24, además de la rama de desarrollo edge. BleepingComputer extiende el riesgo a otros sistemas basados en musl, como OpenWrt, Buildroot o Yocto, muy presentes en routers y dispositivos embebidos. Orca es más prudente y dice que «pueden» estar expuestos. Quedan fuera las distribuciones con glibc, como Debian, Ubuntu o Fedora, los servidores que usan PAM y las cuentas bloqueadas con ! en lugar de *.

El caso más delicado son las imágenes oficiales de Alpine para la nube. Su usuario por defecto, alpine, puede usar doas, el equivalente ligero de sudo, sin contraseña. Si alguien entra en esa cuenta, puede convertirse en administrador. Detectify matiza que esas imágenes son seguras en el primer arranque y solo quedan expuestas cuando se asigna una contraseña a otra cuenta, por ejemplo para entrar por consola. Sobre la cuenta root también hay matices: Detectify señala que la configuración por defecto PermitRootLogin prohibit-password la protege.

La letra pequeña: parche, reinicio y revisión

La corrección llega con OpenSSH 10.6p2, y Alpine ha publicado paquetes actualizados para sus ramas. Hay un detalle importante que recalcan Orca y Detectify: actualizar el paquete no reinicia el servicio que ya está en marcha. Hay que reiniciar sshd a mano o el servidor seguirá siendo vulnerable.

Si no se puede actualizar de inmediato, la medida de emergencia es desactivar el acceso por contraseña (PasswordAuthentication no) y reiniciar el servicio, comprobando antes que el acceso con clave funciona para no quedarse fuera. También conviene revisar los registros: un inicio de sesión con contraseña en una cuenta que tiene un asterisco en /etc/shadow es una señal clara de intrusión. Según Orca y Detectify, un equipo en esa situación debe tratarse como comprometido.

A 5 de noviembre no había constancia de ataques reales, aunque Orca advierte de que la información publicada basta para reproducir el fallo. Detectify espera que pronto empiecen los escaneos masivos en busca de equipos vulnerables.

Por qué importa

Alpine está detrás de muchísimos contenedores, servidores pequeños y dispositivos conectados, y SSH es la puerta por la que se administran. *sshole recuerda dos lecciones que van más allá de esta distribución. La primera es que un valor de error mal elegido, como un asterisco que también significa «cuenta bloqueada», puede convertirse en una llave maestra. La segunda es que las correcciones de seguridad interactúan entre sí de formas que nadie había previsto. Para cualquiera que gestione un servidor, la receta es la de siempre: actualizar, reiniciar los servicios y, si es posible, usar claves en lugar de contraseñas.