Vulnerabilidad en Linux permite login sin contraseña: el bug que duró una década

Un error de configuración que parecía una buena práctica de seguridad terminó convirtiéndose en una vulnerabilidad crítica. La falla, bautizada como *sshole y registrada como CVE-2026-123158, permite a un atacante entrar de forma remota a ciertos sistemas Linux sin conocer la contraseña de la cuenta objetivo.

Según la investigación del investigador Özgün Kültekin, el problema afecta principalmente a configuraciones de Alpine Linux que usan OpenSSH junto con la biblioteca musl y sin PAM. Otras distribuciones podrían verse afectadas si cumplen las mismas condiciones exactas.

El bug se originó por una cadena de cambios realizados en diferentes años con buenas intenciones. En 2012, musl modificó cómo reportaba ciertos errores y agregó un límite de longitud en el procesamiento de contraseñas. En 2016, OpenSSH ajustó su comportamiento para evitar enumeración de usuarios. Y en 2022, Alpine cambió la configuración de su cuenta predeterminada para facilitar el uso de claves SSH. La interacción inesperada entre estos cambios creó el problema.

El mecanismo es peculiar: cuando se intenta autenticar una cuenta que tiene un asterisco (*) en /etc/shadow (lo que debería bloquear el uso de contraseñas), el sistema compara con datos de otra cuenta. Si la contraseña enviada tiene entre 257 y 1.024 bytes, musl devuelve un asterisco como error. El servidor SSH interpreta esa coincidencia y permite el acceso.

No todos los usuarios de Alpine Linux están en riesgo. Para que el fallo sea explotable deben cumplirse varias condiciones al mismo tiempo: OpenSSH sin PAM, autenticación por contraseña habilitada, una cuenta con asterisco y otra cuenta local con hash SHA-256 o SHA-512. Los sistemas que desactivaron completamente las contraseñas o usan PAM quedan fuera de peligro.

El riesgo se agrava cuando la cuenta vulnerable tiene privilegios elevados. En algunas imágenes de Alpine usadas en la nube, el usuario predeterminado puede ejecutar comandos de administrador sin contraseña adicional mediante doas. Si se agrega una cuenta con hash compatible, un atacante podría tomar control total del servidor.

Ya hay evidencia de explotación en la naturaleza: la firma Previdian detectó intentos desde una misma IP y confirmó un acceso administrativo exitoso en uno de sus honeypots.

La solución llegó rápido. El 5 de noviembre se publicaron las correcciones: OpenSSH 10.6p2 y actualizaciones para varias ramas de Alpine Linux. Instalar los parches no es suficiente: es obligatorio reiniciar el servicio SSH para que tome el código corregido.

Si no podés actualizar de inmediato, la recomendación oficial es desactivar la autenticación por contraseña en el archivo de configuración de SSH, verificar que el acceso por claves funcione correctamente y luego reiniciar el servicio.

Este caso sirve como recordatorio de cómo decisiones de seguridad tomadas de forma aislada pueden generar problemas inesperados cuando interactúan años después. En entornos de servidores y cloud, donde Alpine es muy utilizado por su ligereza, conviene revisar la configuración cuanto antes.