Algunas cuentas de servidor están configuradas para que ninguna contraseña pueda abrirlas nunca. Solo deben usarse con una llave SSH, o no usarse en absoluto. Durante diez años, en una familia de sistemas Linux, esas cuentas aceptaban cualquier contraseña, siempre que tuviera más de 256 caracteres. La falla se hizo pública el 5 de noviembre, y los atacantes ya la estaban usando al día siguiente.
Qué pasó
En Linux, una cuenta que nunca debe iniciar sesión con contraseña tiene un asterisco (*) donde normalmente iría el hash de su contraseña. Un asterisco no es un hash válido, así que ninguna contraseña puede coincidir con él. Muchas cuentas que solo usan llaves, cuentas de servicio y la cuenta root de Alpine están configuradas así.
Dos decisiones tomadas con años de diferencia rompieron esa regla. En 2012, la biblioteca de C musl, que Alpine y muchos sistemas Linux pequeños usan en lugar de la más común glibc, decidió que cuando su función de hash de contraseñas falla devolvería un asterisco en vez de nada. Más o menos al mismo tiempo limitó las contraseñas a 256 bytes, así que una más larga hace que el hash falle. En 2016, OpenSSH corrigió otro error calculando el hash de cada contraseña enviada incluso para cuentas sin un hash utilizable, para no revelar qué nombres de usuario existen.
Juntas, una contraseña de más de 256 bytes hace que el hash falle, la falla devuelve un asterisco, y OpenSSH compara ese asterisco con el asterisco guardado para la cuenta bloqueada. Coinciden, y el atacante entra. Kültekin la encontró compilando OpenSSH de todas las formas que se le ocurrieron y lanzando unos 17,600 inicios de sesión inusuales contra cada versión. Todas las versiones coincidieron en todos los inicios de sesión, excepto musl sin PAM.
OpenSSH publicó una corrección la misma mañana en que se reveló. La explicación del investigador llegó tres horas después, y el código de ataque estaba en GitHub menos de una hora más tarde. GreyNoise registró su primera explotación exitosa unas 40 horas después de la corrección. Para el 12 de noviembre había confirmado 42 sesiones de actividad de atacantes en sus servidores señuelo después de una intrusión exitosa, desde diez direcciones. Los atacantes revisaron el sistema, buscaron hashes de contraseñas, llaves SSH y credenciales de la nube, y modificaron archivos, incluso agregando sus propias llaves SSH para poder volver después de que se cerrara el hueco.
Por qué importa
La mayoría de las empresas no sabe cuáles de sus sistemas usan Alpine. Es popular justamente porque es pequeño. Aparece en servidores en la nube que alguien creó a partir de una imagen del marketplace, en contenedores y dentro de equipos donde el dueño ni ve el sistema operativo. Si alguno de ellos tiene SSH abierto a internet con contraseñas permitidas, pudo haber estado abierto a cualquiera.
Las cuentas afectadas son las que más confianza daban. La falla solo afecta a cuentas que se bloquearon a propósito contra contraseñas. Los administradores bloquean las cuentas así porque son sensibles, de modo que la falla cae justo donde más daño hace.
El tiempo entre la corrección y el ataque ahora se mide en horas. La corrección, la explicación y un ataque funcional aparecieron el mismo día. Es el patrón sobre el que seguimos escribiendo: cuando las fallas se encuentran con IA y se publican rápido, los atacantes están listos en un día, así que aplicar parches una vez al mes ya no basta para nada que esté expuesto a internet.
Algunos sistemas comunes están a salvo. Debian, Ubuntu, Fedora y otros sistemas basados en glibc no están afectados, ni tampoco los sistemas que verifican contraseñas a través de PAM. La mayoría de los routers con OpenWrt usan otro servidor SSH, Dropbear, que tampoco está afectado. Un contenedor de Alpine que no ejecuta un servidor SSH tampoco está expuesto.
Qué hacer en la práctica
Encuentra cualquier cosa con OpenSSH sobre Alpine, o sobre Linux embebido, que se pueda alcanzar desde internet. Pregunta a quien administra tus servidores en la nube y tu hosting, y revisa los equipos que ofrecen acceso por SSH. Si no sabes qué sistema usa un equipo, pregunta al fabricante si está afectado por CVE-2026-123158.
Actualiza OpenSSH. En Alpine, ejecuta apk upgrade openssh; hay paquetes corregidos para todas las versiones de Alpine con soporte. En otros sistemas, la corrección es OpenSSH 10.6p2 o la versión parcheada de tu proveedor.
Desactiva el inicio de sesión con contraseña en SSH. Si no puedes actualizar de inmediato, configura PasswordAuthentication no en el servidor SSH y reinícialo. Los servidores accesibles desde internet deberían usar solo llaves SSH de todos modos, y esta opción bloquea el ataque por completo.
Revisa si ya te atacaron. En Alpine, busca inicios de sesión exitosos con contraseña con grep "Accepted password" /var/log/messages. Un inicio de sesión con contraseña en una cuenta que tiene un asterisco en /etc/shadow, como el usuario predeterminado alpine, significa que se usó la falla. Busca también llaves SSH en los archivos authorized_keys que nadie reconozca: los atacantes agregan las suyas para volver después de que apliques el parche.
Si encuentras una intrusión, trata el servidor como comprometido. El parche cierra el hueco, pero no elimina lo que dejó el atacante. Reconstruye el servidor y cambia todas las contraseñas, llaves y credenciales de la nube que tenía.
En resumen
Durante diez años, en una familia popular de sistemas Linux pequeños, las cuentas bloqueadas contra contraseñas se abrían con cualquier contraseña muy larga. Los atacantes empezaron a usarla menos de dos días después de la corrección. Si tienes algo con Alpine o Linux embebido con SSH abierto a internet, actualiza OpenSSH, desactiva el inicio de sesión con contraseña, y revisa los registros y las llaves SSH en busca de señales de que alguien llegó primero.
Fuentes
- OpenSSH 10.6p2 release notes — OpenSSH
- CVE-2026-123158 — Registro CVE
- *sshole — Özgün Kültekin, Wakefield
- SSHole (CVE-2026-123158) activity — GreyNoise
- CVE-2026-123158 — Rastreador de seguridad de Alpine Linux
- Known Exploited Vulnerabilities Catalog — CISA
