sshole: OpenSSH deja entrar a Alpine Linux sin contraseña

Un asterisco contra otro asterisco: así se abre una sesión sin contraseña

Un servidor Alpine Linux con OpenSSH compilado contra musl y sin PAM puede abrir una sesión remota con cualquier contraseña de entre 257 y 1.024 caracteres, sin conocer la real y sin reintentos. La vulnerabilidad, bautizada sshole y registrada como CVE-2026-123158, tiene una gravedad de 8,1 en la escala CVSS, según SecurityWeek, y quedó corregida en OpenSSH 10.6p2, la versión que el proyecto publicó el 5 de noviembre.

Para un equipo que corre producto sobre contenedores, la noticia no es el apodo: es que la imagen base elegida hace tres años puede estar aceptando accesos que nunca debió aceptar, y que el fallo llevaba una década latente dentro de dos decisiones de seguridad que, por separado, eran razonables.

¿Cómo puede un error de contraseña convertirse en una llave de acceso?

En Linux, el archivo /etc/shadow guarda la información con la que se verifican las contraseñas. Cuando el campo correspondiente contiene un asterisco (*), esa cuenta no debe aceptar autenticación por contraseña: es el patrón habitual en cuentas que solo entran con clave criptográfica.

¿Y esto cómo se aplica en tu negocio?

Dueños de negocio de Latinoamérica y España usan un agente de IA para ganar más y recuperar su tiempo. El Kit «tu mano derecha con IA» te muestra cómo en un video de 11 minutos, con una ficha para armar el tuyo. CAR está cerrada por ahora; al anotarte, te avisamos cuando abra.

👥 Quiero el Kit →

El fallo aparece cuando OpenSSH intenta verificar una contraseña para una de esas cuentas. Como no encuentra un hash utilizable, toma prestada la sal de otra cuenta y procesa la contraseña de todos modos. Esa decisión se remonta a 2016, cuando sshd se modificó para cerrar un problema de tiempos de respuesta que permitía averiguar qué usuarios existían en un servidor (CVE-2016-6210), según la reconstrucción difundida por Help Net Security.

Del otro lado, la función crypt() de musl rechaza desde 2012 las contraseñas SHA-256 y SHA-512 de más de 256 bytes, y cuando falla devuelve un asterisco. sshd compara ese asterisco con el asterisco guardado en la cuenta protegida, los interpreta como coincidentes y deja pasar. Un mensaje de error se convierte en credencial válida.

Özgün Kültekin, investigador de Wakefield, construyó sshd en todas las combinaciones que se le ocurrieron y lanzó unas 17.600 pruebas de login inusuales. Solo la variante musl sin PAM aceptó accesos que debía rechazar, según detalla Help Net Security.

¿Qué configuraciones están realmente expuestas?

Usar Alpine no equivale a ser vulnerable. El escenario requiere que varias condiciones coincidan al mismo tiempo:

OpenSSH compilado contra musl y funcionando sin PAM.
Autenticación por contraseña habilitada, que es el ajuste por defecto de OpenSSH.
Una cuenta con un asterisco en el campo de contraseña, como root, un usuario creado con adduser sin contraseña, el usuario alpine de las imágenes oficiales de nube o un usuario que llega desde un servicio de directorio.
Al menos otra cuenta local activa con un hash $5$ o $6$, es decir SHA-256 o SHA-512, de la que sshd pueda tomar la sal.

Alpine confirmó, según SecurityWeek, que las versiones afectadas incluyen todas las que revisó, de la 3.16 a la 3.24 y la rama edge, además de las ramas antiguas que ya no reciben actualizaciones regulares. También señaló como candidatas a revisar otras plataformas basadas en musl como OpenWrt, Buildroot y Yocto.

Quedan fuera del radio las distribuciones que usan glibc —Debian, Ubuntu y Fedora entre ellas—, cualquier instalación que verifique contraseñas a través de PAM, Dropbear y OpenBSD.

Ya hay explotación confirmada: menos de nueve horas

La firma Previdian detectó intentos dirigidos al fallo y confirmó acceso con privilegios de administrador en uno de sus servidores señuelo con Alpine y OpenSSH reales. El primero llegó menos de nueve horas después de la publicación del CVE, explicó su fundador Ryan Dewhurst a Help Net Security.

El patrón es el de siempre: todos los intentos salieron de una sola dirección IP con base en Japón y ejecutaron comandos de reconocimiento —id, uname y hostname— en sesiones no interactivas. Previdian sumó la vulnerabilidad a su propia lista de fallos explotados; CISA todavía no la incorporó a su catálogo KEV. En la práctica, eso significa que nadie va a avisarte por esa vía y la decisión de parchear es tuya.

El investigador Fredrik Almroth, cofundador de Detectify, puso la escala del problema en términos muy concretos para SecurityWeek: Shodan lista alrededor de 22 millones de sistemas con SSH abierto en el puerto 22, y solo algunos corren Alpine, pero como cada intento es una sola conexión, a un atacante le sale gratis probar contra todos.

¿Por qué la nube es el escenario más incómodo?

En las imágenes oficiales de Alpine para AWS y Azure, el usuario alpine tiene doas sin contraseña, el sustituto de sudo en ese ecosistema. Entrar por ahí equivale a entrar como root. SOCRadar acotó las imágenes tiny-cloud afectadas entre las versiones 3.18.11 y 3.24.3, según recoge Help Net Security.

La cuenta root de Alpine lleva el asterisco desde la rama 3.16, pero el ajuste por defecto de OpenSSH bloquea su acceso directo con contraseña salvo que un administrador lo haya cambiado. El riesgo real es el acceso indirecto: una cuenta sin contraseña con permisos elevados es una puerta trasera esperando una condición más.

El parche no sirve si no reinicias el servicio

OpenSSH 10.6p2 corrige el problema. Alpine, por su parte, publicó paquetes parcheados para sus ramas, entre ellos 3.21.10, 3.22.8, 3.23.8 y 3.24.4, según Infobae.

El detalle que más se está pasando por alto: instalar la actualización no cambia el binario que ya está corriendo en memoria. El sshd viejo sigue aceptando conexiones hasta que se reinicia el servicio. En un contenedor eso implica reconstruir y desplegar la imagen, no solo ejecutar una actualización dentro del contenedor en marcha.

Si actualizar no es posible hoy, Damien Miller, desarrollador de OpenSSH, pidió en Mastodon cortar por lo sano: fijar PasswordAuthentication en no o directamente apagar SSH en esos sistemas, y reiniciar el servicio para aplicar el cambio. Antes conviene comprobar que el acceso por claves funciona, o el remedio deja a tu equipo fuera del servidor.

La señal de fondo: los agentes de IA están encontrando bugs en horas

Hay una capa de esta historia que importa más allá de Alpine. Miller explicó que la versión salió lo más rápido posible porque el proyecto ha observado varios casos de redescubrimiento veloz de fallos por parte de agentes de IA, a veces en cuestión de horas, y por eso considera que los embargos largos son una práctica peligrosa que beneficia sobre todo a los atacantes, según SecurityWeek.

Kültekin, por su parte, reconoció haber usado enjambres de agentes para hacer sus pruebas. Es la misma dinámica que Dewhurst describió a Help Net Security al explicar por qué la explotación llegó tan rápido: el fallo era trivial de explotar y los atacantes trabajan cada vez más rápido con ayuda de inteligencia artificial.

Para un equipo pequeño, la lectura práctica es incómoda: la ventana entre «hay un CVE publicado» y «alguien está barriendo tu puerto» se está comprimiendo. Un proceso de parcheo pensado en semanas ya no cubre ese margen.

¿Cómo saber si ya entraron en tus servidores?

SOCRadar recomienda buscar en /var/log/messages las entradas «Accepted password for» asociadas a cuentas que no usan contraseña, como alpine, root o usuarios de solo llave. Conviene además revisar el uso de doas, los usuarios creados recientemente y los archivos authorized_keys.

Si no puedes descartar un acceso de ese tipo, la máquina se trata como comprometida, no como sospechosa. Y ojo con las pruebas de concepto publicadas en GitHub: Previdian advirtió que no están verificadas y pueden traer malware.

Qué significa esto para tu startup

La vulnerabilidad no afecta a todo el mundo, pero el tipo de error sí: dos medidas de seguridad correctas que, combinadas, producen lo contrario de lo que buscaban. Así se construye la deuda técnica que nadie ve hasta que aparece un CVE.

Acciones concretas que puedes ejecutar esta semana:

Haz inventario de lo que corre en musl. Revisa los Dockerfile y las imágenes base con FROM alpine, más cualquier despliegue en OpenWrt, Buildroot o Yocto si tienes hardware propio. Confirma si el openssh-server de esa imagen va sin PAM y con autenticación por contraseña activa.
Desactiva la autenticación por contraseña en todo lo que puedas. Es la mitigación más barata y elimina el vector completo. Si dependes de contraseñas para algún acceso, ese es el problema de fondo que este fallo acaba de exponer.
Reconstruye imágenes, no solo actualiza paquetes. Un apk upgrade dentro de un contenedor en ejecución no reemplaza el proceso sshd que está escuchando. El parche entra cuando la imagen nueva se construye y el servicio arranca de cero.
Audita los logs antes de dar por cerrado el incidente. Busca inicios de sesión por contraseña en cuentas que no deberían usarla y revisa claves autorizadas que no reconozcas. Si tu producto maneja datos de clientes, esa revisión también es un requisito de cumplimiento.

Conclusión: la seguridad por defecto dejó de ser un detalle de infraestructura

Este fallo no nació de un error descuidado, sino de la interacción de tres parches legítimos aplicados en años distintos: musl limitando la longitud de contraseñas desde 2012, OpenSSH cerrando una fuga de información en 2016 y Alpine endureciendo su cuenta root en 2022. Nadie hizo nada mal y aun así el resultado permitía entrar sin contraseña durante una década.

Para un founder, la conclusión es que la configuración por defecto de una imagen base es una decisión de producto, no un detalle de sistemas. Un equipo de dos personas no puede auditar cada capa de su stack, pero sí puede reducir superficie: menos contraseñas, más claves, inventario actualizado de imágenes y un procedimiento de parcheo que contemple el reinicio del servicio y no solo la descarga del paquete.