Una vulnerabilidad crítica, denominada *sshole (CVE-2026-123158), ha sido descubierta en ciertas configuraciones de sistemas Linux, permitiendo el acceso remoto a cuentas sin necesidad de una contraseña válida. Este fallo afecta a entornos que combinan OpenSSH con la biblioteca musl y prescinden de PAM, un mecanismo de autenticación. El problema reside en cómo el sistema interpreta un asterisco en el campo de contraseña, habilitando un acceso no autorizado.
Existen decisiones destinadas a fortalecer la seguridad de un sistema que, en teoría, parecen incuestionables. Una de ellas es la de restringir que ciertas cuentas acepten contraseñas, obligando al uso de otros métodos de autenticación. Esta práctica es lógica en entornos donde el control de acceso debe ser particularmente estricto. Sin embargo, surge un problema cuando esta misma restricción, diseñada para prevenir entradas no autorizadas, paradójicamente las facilita. Nos encontramos entonces ante una situación confusa: una cuenta protegida contra el uso de contraseñas que, inesperadamente, permite un acceso que debería denegar.
Esta paradoja ya tiene un nombre: *sshole. Así se ha bautizado una vulnerabilidad, identificada como CVE-2026-123158, que posibilita el acceso remoto a ciertas cuentas en sistemas Linux sin conocer una contraseña válida. El fallo se ha confirmado en configuraciones de Alpine Linux que utilizan OpenSSH junto con musl, una biblioteca fundamental del sistema, y no emplean PAM, un mecanismo para la gestión de autenticación. Otras plataformas podrían ser afectadas si presentan las mismas condiciones. El investigador Özgün Kültekin, de Wakefield, fue quien descubrió esta falla, y el 5 de noviembre, tanto OpenSSH como Alpine lanzaron correcciones para mitigar este acceso.
Para comprender cómo es posible este escenario, primero es necesario familiarizarse con SSH, una herramienta ampliamente utilizada para la administración remota de equipos. Este protocolo permite una conexión segura a un ordenador a través de la red, facilitando, por ejemplo, la gestión de un servidor sin necesidad de presencia física. OpenSSH es una de sus implementaciones, y permite la identificación mediante contraseñas o claves criptográficas, que verifican la identidad del usuario de otra manera. En Linux, el archivo /etc/shadow guarda la información usada para verificar las contraseñas de las cuentas. Cuando el campo correspondiente contiene un asterisco (*), la autenticación ordinaria por contraseña debería bloquearse, aunque otros métodos sigan siendo utilizables.
Como detalla Kültekin en su investigación, el fallo se manifiesta cuando OpenSSH intenta verificar una contraseña para una cuenta que no debería aceptarlas. Al no hallar los datos requeridos, el sistema recurre a información de otra cuenta para realizar la verificación. Si la contraseña introducida tiene una longitud entre 257 y 1.024 bytes, la función de musl encargada de su procesamiento devuelve un asterisco para indicar un error. El problema radica en que este mismo símbolo se encuentra en la cuenta protegida: el servidor interpreta ambos valores como coincidentes y concede el acceso.
La historia de este problema se extiende más atrás de lo que parece. Según la reconstrucción del investigador, en 2012, musl modificó su método para comunicar ciertos errores y estableció un límite de longitud al procesar contraseñas para prevenir ataques de denegación de servicio. Cuatro años después, OpenSSH implementó cambios para evitar que se pudiera determinar la existencia de usuarios en un sistema midiendo sus tiempos de respuesta. En 2022, Alpine también ajustó la configuración de su cuenta de administrador para permitir el acceso mediante claves SSH. Estas fueron soluciones a problemas distintos que, finalmente, interactuaron de una forma inesperada.
La pregunta inevitable es qué equipos podrían estar afectados. En primer lugar, utilizar Alpine Linux no implica automáticamente ser vulnerable. Como explica la firma de ciberseguridad Check Point, el fallo requiere que se cumplan varias condiciones simultáneamente, incluyendo que OpenSSH funcione sin PAM, que admita contraseñas y que encuentre una cuenta con el asterisco previamente mencionado. También debe existir otra cuenta local activa con un hash de contraseña generado mediante SHA-256 o SHA-512. Los sistemas que deshabilitan la autenticación por contraseña quedan excluidos de este escenario, al igual que aquellos que emplean PAM para su gestión.
Las consecuencias pueden ser especialmente graves cuando la cuenta comprometida posee permisos elevados. Alpine menciona como ejemplo ciertas imágenes oficiales usadas en la nube, donde el usuario alpine puede ejecutar comandos de administrador mediante doas sin necesidad de introducir una contraseña. Aunque estas imágenes son seguras en su primer arranque, pueden volverse vulnerables si posteriormente se configura una cuenta con un hash de contraseña compatible. En tal escenario, un atacante podría llegar a controlar el sistema. Ya existen indicios de explotación: la firma Previdian afirma haber detectado ocho intentos desde una misma dirección IP y ha confirmado un acceso con privilegios de administrador en uno de sus servidores señuelo diseñados para detectar ataques.
La respuesta al descubrimiento ha sido inmediata. OpenSSH lanzó el 5 de noviembre la versión 10.6p2 para corregir el fallo, mientras que Alpine distribuyó actualizaciones para diversas ramas de su sistema, incluyendo algunas antiguas. Los responsables advierten que la simple instalación de los parches no es suficiente: también es indispensable reiniciar el servicio SSH para que utilice el código corregido. Si la actualización no es posible de inmediato, recomiendan desactivar la autenticación mediante contraseña y también reiniciar el servicio para aplicar el cambio, verificando previamente que el acceso mediante claves funcione.
