Vulnerabilidad crítica descubierta en sistemas Linux sin contraseña

Un fallo de seguridad grave ha sido identificado en diversos sistemas Linux que opera bajo condiciones específicas, permitiendo a atacantes acceder remotamente sin necesidad de conocer la contraseña válida. La vulnerabilidad Linux sin contraseña, identificada con el código CVE-2026-123158, representa una amenaza significativa para administradores de sistemas que no han aplicado los parches correspondientes. El investigador de seguridad Özgün Kültekin, procedente de Wakefield, descubrió este defecto y reportó sus hallazgos tanto a OpenSSH como a Alpine Linux el 5 de noviembre de 2026.

Este fallo, bautizado como *sshole, es el resultado de una combinación particular de elementos de software que interaccionan de manera inesperada. Los sistemas afectados específicamente incluyen configuraciones de Alpine Linux que integran OpenSSH con la biblioteca musl, mientras prescinden de PAM (Pluggable Authentication Modules), un mecanismo estándar para gestionar procesos de autenticación en sistemas Unix y Linux.

Cómo funciona el ataque a través de la vulnerabilidad Linux sin contraseña

Para comprender cómo es posible este acceso no autorizado, es fundamental entender el rol del protocolo SSH. Este protocolo es ampliamente utilizado para administrar equipos a distancia de forma segura, permitiendo a administradores conectarse a servidores sin estar físicamente presentes. OpenSSH es una de las implementaciones más populares de SSH, ofreciendo autenticación mediante contraseñas o claves criptográficas que verifican la identidad del usuario.

En sistemas Linux, la información utilizada para validar contraseñas se almacena en el archivo /etc/shadow. Cuando el campo correspondiente a una cuenta contiene un asterisco (*), la autenticación ordinaria mediante contraseña debería estar completamente bloqueada, aunque otros métodos de autenticación podrían seguir siendo funcionales. Sin embargo, la vulnerabilidad Linux sin contraseña surge cuando OpenSSH intenta verificar una contraseña para una cuenta que no debería aceptarlas.

El mecanismo del fallo es particularmente ingenioso en su sencillez. Cuando OpenSSH no encuentra los datos necesarios en la cuenta protegida para verificar una contraseña, utiliza información proveniente de otra cuenta para efectuar la comprobación. Si la contraseña introducida tiene una longitud específica, entre 257 y 1.024 bytes, la función responsable de procesarla en la biblioteca musl devuelve un asterisco para indicar un error. El servidor interpreta entonces ambos valores, el asterisco de la cuenta protegida y el asterisco devuelto por la función, como coincidentes, permitiendo erróneamente el acceso.

El trasfondo: una década de interacciones inesperadas

La historia de esta vulnerabilidad Linux sin contraseña se extiende muchos años atrás, revelando cómo decisiones tomadas independientemente en diferentes épocas terminan confluyendo de manera peligrosa. En 2012, musl realizó modificaciones en la forma de comunicar ciertos errores e implementó un límite de longitud al procesar contraseñas, una medida diseñada para prevenir ataques de denegación de servicio que habrían podido saturar sistemas con solicitudes excesivas.

Cuatro años después, en 2016, OpenSSH introdujo cambios enfocados en impedir que atacantes pudieran identificar qué usuarios existían en un sistema midiendo los tiempos de respuesta de las solicitudes de autenticación. Esta fue una mejora defensiva contra técnicas de enumeración de usuarios. Posteriormente, en 2022, Alpine ajustó la configuración de su cuenta de administrador para permitir el acceso mediante claves SSH, una decisión que facilitaba la administración remota sin dependencia de contraseñas.

Cada una de estas soluciones abordaba problemas diferentes y válidos en su contexto, pero su confluencia en sistemas que ejecutaban estas tres tecnologías simultáneamente creó un escenario donde la seguridad se veía comprometida de manera totalmente imprevista.

Qué sistemas están realmente en riesgo

Una pregunta fundamental surge tras el descubrimiento de esta vulnerabilidad: ¿qué equipos pueden estar afectados? La respuesta no es automática por el simple hecho de ejecutar Alpine Linux. Según análisis de firmas especializadas en ciberseguridad como Check Point, el fallo requiere que se cumplan varias condiciones simultáneamente para ser explotable.

En primer lugar, OpenSSH debe estar funcionando sin PAM, debe admitir autenticación por contraseña, y debe encontrar una cuenta con el campo de contraseña establecido en asterisco. Además, debe existir otra cuenta local activa con un hash de contraseña generado específicamente mediante SHA-256 o SHA-512. Los sistemas que desactivan completamente la autenticación por contraseña quedan fuera de este escenario de vulnerabilidad, al igual que aquellos que utilizan PAM para gestionar la autenticación, ya que implementan capas adicionales de validación que previenen este tipo de bypass.

Impacto potencial en entornos de producción

Las consecuencias de esta vulnerabilidad Linux sin contraseña pueden ser particularmente graves cuando la cuenta comprometida dispone de permisos elevados. Alpine proporciona un ejemplo alarmante: en determinadas imágenes oficiales utilizadas en entornos de nube, la cuenta 'alpine' puede ejecutar comandos de administrador mediante doas sin necesidad de introducir contraseña. Aunque estas imágenes son seguras en su arranque inicial, pueden volverse vulnerables si posteriormente se configura una cuenta con un hash de contraseña compatible.

En ese escenario adverso, un atacante podría lograr el control completo del sistema comprometido. Las indicaciones de que esta vulnerabilidad está siendo explotada activamente son preocupantes: la firma de seguridad Previdian ha reportado haber detectado ocho intentos de explotación desde una misma dirección IP, y confirmó un acceso exitoso con privilegios de administrador en uno de sus servidores señuelo utilizados para detectar y analizar ataques.

Medidas de corrección y recomendaciones

La respuesta de los desarrolladores ante el descubrimiento ha sido rápida y decisiva. OpenSSH publicó el 5 de noviembre la versión 10.6p2 específicamente para corregir este fallo, mientras que Alpine distribuyó actualizaciones para distintas ramas de su sistema operativo, incluyendo versiones antiguas que seguían siendo utilizadas en producción. Sin embargo, instalar los parches de actualización no es suficiente por sí solo.

Los responsables de Alpine han advertido explícitamente que es necesario reiniciar el servicio SSH después de aplicar las actualizaciones para que el sistema comience a utilizar el código corregido. Si por alguna razón una actualización inmediata no es posible en su entorno, recomiendan enérgicamente desactivar la autenticación mediante contraseña como medida temporal, seguido del reinicio del servicio SSH para aplicar este cambio. Antes de implementar cualquier restricción, es fundamental verificar que el acceso mediante claves criptográficas funciona correctamente para evitar quedar bloqueado del sistema.

Conclusión: la importancia de la supervisión de seguridad

Este incidente subraya una lección crítica sobre la seguridad informática: incluso decisiones defensivas bien intencionadas pueden generar vulnerabilidades no previstas cuando interactúan en combinaciones específicas. La vulnerabilidad Linux sin contraseña permanece latente durante años antes de ser descubierta, demostrando que la supervisión constante y el análisis de seguridad son esenciales en la administración de sistemas. Administradores y responsables de infraestructura deben revisar sus configuraciones, aplicar actualizaciones urgentemente, y considerar implementar autenticación basada en claves como práctica estándar para acceso remoto.