sshole abre Alpine con una contraseña de 257 caracteres

Una contraseña de 257 caracteres. Sin fuerza bruta, sin adivinar nada. Un solo intento y estás dentro de una cuenta que, en teoría, no debería aceptar contraseña. Eso es sshole, el fallo que el 5 de noviembre de 2026 sacó a OpenSSH y a Alpine Linux a publicar un parche de urgencia.

Lo descubrió Özgün Kültekin, de Wakefield, y en pocas horas ya circulaba por X en español. @elhacker.NET lo resumió sin rodeos: un fallo de OpenSSH que puede saltar la autenticación en servidores Alpine. Si montas contenedores, routers OpenWrt o imágenes cloud con musl, esto te toca más cerca de lo que parece.

Qué pasa exactamente

En Linux, las cuentas que no deben entrar con contraseña llevan un asterisco en el archivo de contraseñas del sistema. No es un hash válido. En teoría, ninguna clave debería abrirlas. Ahí entran root en muchas imágenes de Alpine desde la 3.16, usuarios creados solo con clave SSH o la cuenta alpine de las imágenes tiny-cloud oficiales.

OpenSSH, cuando va sin PAM, comprueba la contraseña con la función de hash de la biblioteca C y compara el resultado con lo guardado. Si el campo es demasiado corto para llevar sal (como ese asterisco), toma prestada la sal de otra cuenta que sí tenga un hash SHA-256 o SHA-512. Bastaba con eso para que, al enviar una clave de entre 257 y 1.024 bytes, la función de musl devolviera justo el mismo asterisco. Coincidencia perfecta. Login aceptado.

Ubuntu, Debian o Fedora con glibc no salen en la foto. El problema nace del cruce entre OpenSSH sin PAM, musl (Alpine, OpenWrt, Buildroot, Yocto) y el login por contraseña activado, que sigue siendo el valor por defecto.

Por qué duele más de lo que parece

No hace falta un identificador con nombre para que duela. Alpine lo dejó escrito con claridad en su aviso del 5 de noviembre: quien llega al puerto SSH puede entrar sin saber ninguna contraseña, en una sola conexión y sin reintentos. SecurityWeek asignó después el identificador CVE-2026-123158, con puntuación CVSS 8.1.

Las condiciones son varias a la vez, y eso da cierta tranquilidad falsa. Hace falta musl, sshd sin PAM (el paquete openssh-server de Alpine va así), contraseñas por SSH activadas, al menos una cuenta con asterisco y otra con un hash real. Si alguna falla, no hay bypass. El detalle molesto es que en muchos entornos esas condiciones se cumplen sin que nadie lo haya pensado.

Las imágenes tiny-cloud de Alpine son el ejemplo que más me ha hecho levantar una ceja. Llevan un usuario alpine con asterisco y doas sin contraseña. Al arrancar están a salvo. En cuanto alguien pone una contraseña de consola o cloud-init crea un usuario con hash, aparece el material necesario y la cuenta alpine queda a un intento. Desde ahí, root es un paso.

Cómo se parchea (y qué no vale)

OpenSSH sacó la 10.6p2 el mismo día. Alpine publicó paquetes corregidos en todas las ramas desde la 3.16 hasta edge. Actualizar el paquete no reinicia el demonio: hay que actualizar con el gestor de paquetes de Alpine y reiniciar sshd después. Si no puedes tocar el binario ya, desactiva el login por contraseña en la configuración de SSH y reinicia el servicio. Cualquiera de las dos cierra el agujero.

BleepingComputer recoge el mismo consejo y añade una pista útil para saber si te han pillado: busca en los logs líneas de acceso aceptado por contraseña para cuentas que no deberían aceptarla. Si alpine o un usuario solo-clave aparecen ahí y su campo de contraseña sigue siendo un asterisco, trata la máquina como comprometida.

A mí me chirría que todavía haya gente con SSH abierto al mundo y login por contraseña en 2026. Las claves SSH llevan años siendo la opción razonable. sshole no inventa esa mala práctica; solo la convierte en una puerta de una sola patada.

El detalle que no quiero dejar pasar

Damien Miller, del proyecto OpenSSH, explicó por qué soltaron el parche tan rápido: han visto agentes de IA redescubrir bugs en cuestión de horas. Mantener un embargo largo, dijo, acaba beneficiando más al atacante que al defensor. SecurityWeek lo recoge en su cobertura del 6 de noviembre.

Eso cambia el ritmo de la divulgación. Antes podías ganar días o semanas mientras los proveedores se organizaban. Ahora el reloj corre distinto. No es una lección abstracta: si tienes Alpine o un firmware con musl y sshd expuesto, el margen para mirarlo el lunes se ha acortado bastante.

Qué haría yo hoy

Si gestionas VPS, NAS caseros con Alpine, routers OpenWrt o pipelines que levantan contenedores con SSH de depuración, prioriza el parche y el reinicio de sshd. Revisa el acceso de root y, de paso, apaga de verdad el login por contraseña. Comprueba los logs. Y si usas las imágenes cloud oficiales antiguas, no asumas que solo es un laboratorio: el escenario de alpine más doas es demasiado cómodo para dejarlo a medias.

sshole no tumba Internet. Tampoco es humo. Es un fallo viejo (la pieza de musl data de 2012; el comportamiento de OpenSSH, de 2016) que alguien ha sabido encadenar en el momento justo. Los que ya entraban solo con clave salen casi indemnes. Los que dejaron la puerta de contraseñas abierta tienen deberes esta misma tarde.