OpenSSH "sshole" (CVE-2026-123158): qué pasó y qué hacer hoy

#Qué pasó, en tres líneas

1. El 5 de noviembre de 2026 se hizo público un fallo, apodado “sshole”, que permite entrar por SSH a ciertos servidores Linux sin conocer la contraseña. Se rastrea como CVE-2026-123158, con una puntuación CVSS de 8.1 (alta).
2. Solo afecta a servidores que usan musl libc (la más conocida es Alpine Linux) con OpenSSH sin PAM y el login por contraseña activado. Ubuntu, Debian, Red Hat y la mayoría de servidores no están afectados.
3. Ya hay arreglo: OpenSSH 10.6p2 y paquetes corregidos de Alpine para las versiones 3.16 a edge. Hay que actualizar y reiniciar sshd. Si no puedes actualizar todavía, desactiva el login por contraseña.

alpinelinux.org · Security advisory

#¿Me afecta? Quién sí y quién no

Tiene que cumplirse todo esto a la vez. Si falta una sola condición, ese servidor no está afectado.

Altamar · ¿Le afecta sshole?

Una aclaración importante: el usuario root de Alpine trae el campo * desde aproximadamente la versión 3.16, pero la configuración por defecto de OpenSSH (PermitRootLogin prohibit-password) lo protege. El riesgo real son otras cuentas sin contraseña que puedan volverse root, por ejemplo con doas. Así lo explica Alpine en su aviso.

#Cómo funciona el fallo (versión simple)

Cuando un servidor con OpenSSH comprueba una contraseña sin PAM, la “cifra” y compara el resultado con lo guardado en el sistema. En las cuentas que no tienen contraseña, lo guardado es un simple asterisco: *.

El problema es que musl, la biblioteca que usa Alpine, también devuelve * cuando le pasan una contraseña demasiado larga (más de 256 bytes), como señal de error. Entonces el servidor compara * con *, ve que coinciden y deja entrar. Ni OpenSSH ni musl tienen un error grave por separado: el fallo está en cómo se combinan.

This is not a cryptographic weakness or a memory-corruption vulnerability. It is an authentication logic failure caused by the interaction between two components that interpret the same value differently.

OpenSSH lo describe así en sus notas de versión:

We consider the root cause of this bug to be outside sshd, but it is exploitable via sshd and can be avoided there.

openssh.org · Release Notes

El fallo lo reportó Özgün Kültekin, de Wakefield, según OpenSSH y Alpine. OX Security cuenta que lo encontró compilando sshd en todas las combinaciones de glibc, musl, PAM y sin PAM, y lanzando “roughly 17,600 deliberately unusual login attempts at each build”.

#Cronología

Altamar · Cronología

• 5 de noviembre de 2026: aviso público en la lista oss-security, publicación de OpenSSH 10.6p2 y aviso de Alpine con paquetes corregidos. El registro CVE-2026-123158 se publicó ese mismo día, con CVSS 8.1 (vector AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H).
• Ese día, The Hacker News escribía: “No attacks using the flaw have been reported.”
• 6 de noviembre: la empresa de inteligencia de amenazas Previdian dijo a Help Net Security que vio el primer intento de explotación a menos de nueve horas de publicado el CVE y que consiguió acceso root en un honeypot propio.

Our first observed attempt arrived less than nine hours after CVE publication, and we’ve confirmed successful root access on a Previdian honeypot running real Alpine Linux and OpenSSH

helpnetsecurity.com

Lo que está en duda: la explotación la reporta una sola empresa, sobre su propio honeypot, con ocho intentos contados desde una única dirección IP en Japón (Help Net Security, The Hacker News). Help Net Security indica que CISA no lo ha incluido en su catálogo de vulnerabilidades explotadas (KEV). No encontramos confirmación independiente. Nuestra recomendación es tratarlo como explotable: el ataque es sencillo y ya circulan pruebas de concepto, que Previdian advierte que no están verificadas y podrían contener malware.

#Qué hacer hoy

1. Haz inventario. Lista todos tus servidores, VPS y contenedores que tengan el puerto SSH abierto. Incluye equipos “olvidados”: routers, gateways, servidores de pruebas.
2. Mira qué sistema usan. cat /etc/os-release. Si dice Alpine, sigue. Si es Ubuntu, Debian o RHEL, ese equipo no está afectado por este fallo (pero sigue siendo buen momento para actualizar).
3. Revisa la versión de OpenSSH. ssh -V muestra la versión instalada. En Alpine no compares con 10.6p2: las ramas estables traen el arreglo como parche sobre su versión. Compara con la tabla de abajo.
4. Actualiza. En Alpine: apk upgrade -U -a.
5. Reinicia sshd. rc-service sshd restart. Actualizar el paquete no reinicia el servicio que ya está corriendo.
6. Si no puedes actualizar hoy, desactiva el login por contraseña. Pon PasswordAuthentication no en la configuración de sshd y reinicia. Antes, comprueba que tu login con llave funciona y deja abierta tu sesión actual hasta probar una nueva. Verifica con sshd -T | grep -i passwordauthentication, que debe mostrar passwordauthentication no.
7. Revisa tus imágenes de contenedor y de nube. Si tus contenedores Alpine corren sshd dentro, reconstrúyelos desde una imagen base corregida. Si usas imágenes tiny-cloud de Alpine de antes de 3.21.10, 3.22.8, 3.23.8 o 3.24.4, actualiza openssh en cada instancia que esté corriendo.
8. Busca señales de intrusión. En /var/log/messages, busca líneas de sshd Accepted password for en cuentas que no tienen contraseña (alpine, root o usuarios solo con llave). Revisa el uso de doas, usuarios creados hace poco y archivos authorized_keys.

Fuente: aviso de Alpine y su base de datos de seguridad (secdb), consultada el 7 de noviembre de 2026. La rama 3.15 y anteriores no tienen arreglo publicado: si tienes algo tan viejo, la salida es migrar o desactivar el login por contraseña.

If you cannot rule out a login, treat the machine as compromised.

#Lecciones para cualquier negocio

• Parchear rápido importa. Entre el aviso y el primer intento de ataque reportado pasaron horas, no semanas. Ten un responsable y un proceso para aplicar parches de seguridad el mismo día.
• No puedes proteger lo que no sabes que tienes. Muchos negocios no saben cuántos servidores, VPS o contenedores tienen corriendo, ni con qué sistema. Un inventario simple (qué hay, dónde, quién lo mantiene) es lo primero.
• Las imágenes viejas son un riesgo silencioso. Una imagen de contenedor que nadie reconstruye sigue con sus fallos aunque el sistema “ya se haya arreglado”.
• Menos puertas abiertas. Si un servidor no necesita SSH abierto a internet, ciérralo o ponlo detrás de una VPN. Y usa llaves en lugar de contraseñas.
• Vigila los logs. Saber quién entró, cuándo y cómo es lo que permite responder la pregunta “¿nos atacaron?”.

#Cómo puede ayudar Altamar

Si no sabes con certeza qué servidores tienes ni si alguno usa Alpine con SSH abierto, podemos ayudarte a hacer ese inventario, aplicar el arreglo y dejar un proceso para la próxima vez. Agenda una llamada con uno de nuestros ingenieros.

#Referencias

Todas consultadas el 7 de noviembre de 2026.

• OpenSSH, notas de la versión 10.6p2 (5 nov 2026): openssh.org/releasenotes.html
• Anuncio en openssh-unix-announce (5 nov 2026): lists.mindrot.org
• Jan Schaumann, oss-security, “sshole”: password authentication bypass (5 nov 2026): openwall.com
• Registro CVE-2026-123158: cve.org y NVD
• Alpine Linux, aviso de seguridad (5 nov 2026): alpinelinux.org
• Alpine Linux, rastreador de seguridad: security.alpinelinux.org y secdb
• OX Security, análisis técnico (5 nov 2026): ox.security
• BleepingComputer (5 nov 2026): bleepingcomputer.com
• The Hacker News, “OpenSSH Issues Emergency Fix…” (5 nov 2026): thehackernews.com
• The Hacker News, “Hackers Target OpenSSH SSHole Flaw Within Hours of Disclosure…” (6 nov 2026): thehackernews.com
• Help Net Security (6 nov 2026): helpnetsecurity.com
• GIGAZINE (6 nov 2026, en japonés): gigazine.net