OpenSSH ha publicado la versión 10.6p2 para corregir SSHole (CVE-2026-123158), un fallo que ya se explota y que permite entrar en servidores Alpine Linux con una contraseña muy larga. Afecta a sistemas Linux con musl libc y PAM desactivado. Si tienes Alpine con SSH abierto, actualiza hoy o desactiva el acceso por contraseña.
Lo esencial
- El fallo es CVE-2026-123158 (CVSS 8.1), apodado SSHole. Afecta a Linux con OpenSSH sobre musl libc y PAM desactivado, incluida la configuración por defecto del servidor OpenSSH de Alpine Linux (The Hacker News).
- En esos sistemas, algunas cuentas aceptan cualquier contraseña de entre 257 y 1024 caracteres, según SecurityWeek.
- OpenSSH 10.6p2 corrige el fallo y el proyecto lo califica de crítico. Alpine ha publicado paquetes corregidos para todas sus versiones hasta la 3.16.
- Previdian detectó el primer intento de explotación menos de nueve horas después de publicarse el CVE y confirmó acceso root en un honeypot con Alpine (The Hacker News).
- INCIBE-CERT publicó el aviso «Omisión de autenticación por contraseña en OpenSSH de Alpine Linux» el 6 de noviembre de 2026, con severidad alta (INCIBE-CERT).
¿Me afecta si mis servidores usan Ubuntu, Debian o Windows?
No. Según Damien Miller, de OpenSSH, no están afectados los sistemas que no son Linux, los Linux con glibc ni los que validan contraseñas mediante PAM. Ubuntu, Debian y RHEL usan glibc. Windows queda fuera. Dropbear, el servidor SSH por defecto de OpenWrt, tampoco está afectado.
El riesgo real lo tiene quien ejecuta servidores, máquinas virtuales o contenedores con Alpine Linux y un servidor OpenSSH accesible desde Internet. Es habitual en startups y pymes con infraestructura propia o en la nube, y en proveedores de desarrollo o hosting. Si alguien te gestiona la infraestructura, la pregunta va para él.
¿Cómo puede una contraseña larga abrir la puerta?
Cuando la contraseña es demasiado larga, el cálculo del hash falla y devuelve «*». Ese mismo valor es el que marca una cuenta con la contraseña desactivada. El código interpreta esa coincidencia como una autenticación correcta.
La consecuencia es incómoda: las cuentas expuestas son las que no tienen contraseña, por ejemplo las que solo usan clave SSH. Justo las que muchos equipos consideran más seguras. El origen está en un parche de 2016 para CVE-2016-6210, así que el error lleva años en producción.
¿Se está explotando de verdad?
Sí. El día de la publicación del parche aún no se habían notificado ataques. El 6 de noviembre se supo que Previdian había registrado ocho intentos desde una IP geolocalizada en Japón. Los atacantes usaron contraseñas sobredimensionadas, obtuvieron acceso root en el honeypot y ejecutaron comandos de reconocimiento como id, uname y hostname. Es el paso previo a decidir qué hacer con la máquina.
Qué hacer hoy
- Pide a tu equipo de TI o a tu proveedor un inventario de sistemas Alpine con sshd activo, incluidos contenedores y máquinas virtuales.
- Actualiza a OpenSSH 10.6p2 o instala los paquetes corregidos de Alpine.
- Si no puedes actualizar hoy, pon PasswordAuthentication=no en la configuración de sshd o desactiva SSH en esos sistemas, como recomienda Damien Miller.
- Limita el acceso SSH por IP, VPN o bastión para que no quede abierto a todo Internet.
- Revisa los logs de sshd desde el 5 de noviembre: busca autenticaciones con contraseñas anómalamente largas o accesos inesperados.
- Si no tienes sistemas Alpine con SSH, no tienes que hacer nada más.
Qué significa para una pyme
Menos de nueve horas entre la publicación del CVE y el primer intento de explotación. Si tu ciclo de parches se mide en semanas, este fallo te pilla con la puerta abierta. No hace falta pánico, pero sí capacidad de reaccionar el mismo día.
El trabajo difícil aquí no es parchear, es saber si tienes Alpine. Suele llegar dentro de imágenes de contenedor o de servidores que montó un proveedor, no por una decisión consciente. Si nadie en tu empresa puede responder en una hora qué sistemas tienen SSH expuesto y con qué distribución, ese es el problema que te deja SSHole al descubierto.
La segunda lección es de configuración. Muchos equipos creen que usar solo claves SSH les protege, pero el servidor seguía aceptando contraseñas. Desactivar la autenticación por contraseña en todo el servidor, no cuenta a cuenta, y no exponer SSH directamente a Internet habría neutralizado este fallo antes de existir el parche. Si quieres revisar cómo tienes expuesta tu infraestructura, en ciberseguridad trabajamos justo ese inventario.
Preguntas frecuentes
Solo uso claves SSH, ¿estoy a salvo?
No necesariamente. Las cuentas sin contraseña, como las que solo usan clave, son precisamente las afectadas si el servidor sigue aceptando contraseñas. Pon PasswordAuthentication=no o actualiza.
¿Afecta a mi router con OpenWrt?
No con la configuración por defecto. OpenWrt usa Dropbear, que no está afectado.
Ya he actualizado, ¿he terminado?
No del todo. El fallo se explota desde hace días, así que revisa los logs de sshd desde el 5 de noviembre por accesos inesperados.
Fuentes
- The Hacker News – Hackers Target OpenSSH SSHole Flaw Within Hours of Disclosure, Gain Root on Honeypot
- The Hacker News – OpenSSH Issues Emergency Fix for Flaw Letting Long Passwords Bypass SSH Auth on Alpine Linux
- INCIBE-CERT – Avisos (Omisión de autenticación por contraseña en OpenSSH de Alpine Linux, 06/11/2026)
