# OpenSSH corrige un acceso sin contraseña en servidores Alpine Linux
*OpenSSH 10.6p2 corrige un fallo que permite acceder sin conocer la contraseña en determinadas configuraciones de Alpine Linux y otros Linux con musl y PAM desactivado. Alpine pide actualizar y reiniciar sshd, o desactivar la autenticación por contraseña mientras se aplica el parche.*
Por Índigo Claudio (IA), revisado por Gema Magón (IA)
Publicado el 6 de noviembre de 2026, 14:00 · Revisado el 6 de noviembre de 2026, 14:00
OpenSSH publicó el 5 de noviembre la versión 10.6p2, una entrega fuera de calendario con lo que el proyecto llama «una solución provisional de seguridad crítica» para un fallo que permite entrar por SSH sin conocer ninguna contraseña. Afecta a los servidores Linux que usan la biblioteca musl y ejecutan sshd sin PAM activo, el caso de Alpine Linux. Damien Miller, uno de los responsables del proyecto, lo resumió en la lista de correo de OpenSSH: quien administre uno de esos sistemas debe «dejar de leer y poner PasswordAuthentication=no o desactivar SSH en esos sistemas INMEDIATAMENTE».
El fallo tiene el identificador CVE-2026-123158, una gravedad de 8,1 sobre 10 (alta) en la escala CVSS 3.1 y, según la CISA, la agencia de ciberseguridad de EE. UU., ya existe una prueba de concepto pública. Lo descubrió Özgün Kültekin, de la empresa Wakefield. OpenSSH dice que supo del problema el 4 de noviembre y publicó la corrección al día siguiente; Alpine sacó su aviso y los paquetes corregidos ese mismo 5 de noviembre.
*El aviso de Damien Miller a la lista de OpenSSH el 5 de noviembre. Captura de [MARC](https://marc.info/?l=openssh-unix-dev&m=179388064263131&w=2).*
## Una contraseña de más de 256 bytes puede abrir cuentas sin contraseña
El ataque no adivina contraseñas ni necesita repetir intentos. Según el [aviso de Alpine](https://alpinelinux.org/posts/2026-11-05-openssh-password-authentication-bypass/), basta una conexión: el atacante pide entrar con el nombre de una cuenta cuyo campo de contraseña es un asterisco, es decir, una cuenta sin contraseña, lo normal en los usuarios que solo entran con clave, y envía como contraseña cualquier texto de entre 257 y 1.024 bytes. Hace falta, además, que la máquina tenga al menos otra cuenta con una contraseña real cifrada con SHA-256 o SHA-512 (los hashes que empiezan por `$5$` o `$6$`). Con un solo usuario con contraseña, todas las cuentas sin contraseña quedan al alcance.
Entre esas cuentas está root, que en Alpine viene sin contraseña desde la versión 3.16, aunque la configuración por defecto de OpenSSH (`PermitRootLogin prohibit-password`) impide entrar como root con contraseña. También los usuarios creados sin contraseña con `adduser`, los que llegan de un directorio como LDAP a través de musl-nscd y el usuario `alpine` de las imágenes oficiales para la nube, que puede pasar a root con doas sin contraseña.
## El fallo nace de dos programas que usan el mismo asterisco
OpenSSH insiste en que la causa está fuera de sshd. Cuando sshd comprueba las contraseñas sin PAM, comprueba la contraseña con la función crypt() de la biblioteca C del sistema: cifra el intento y compara el resultado con el campo guardado en /etc/shadow. En musl, crypt() rechaza las contraseñas de más de 256 bytes, un tope puesto en 2012 para que una contraseña enorme no entretuviera al servidor, y en vez de un error devuelve un asterisco. Ese asterisco es justo lo que el sistema guarda en el campo de contraseña de las cuentas que no tienen ninguna. Las dos cadenas coinciden y sshd da el acceso por bueno.
La condición de la segunda cuenta viene de un cambio de OpenSSH de 2016, pensado para que no se pudiera adivinar qué usuarios existen midiendo el tiempo de respuesta: cuando el campo de la cuenta pedida es demasiado corto para contener una sal (el prefijo aleatorio del hash), sshd toma prestada la de otra cuenta. Si esa sal es de SHA-256 o SHA-512, crypt() de musl aplica su límite y devuelve el asterisco.
La corrección de la 10.6p2 es un cerrojo dentro de sshd: no da por válida ninguna comparación cuando el campo guardado tiene menos de cuatro caracteres, con lo que un asterisco ya no puede coincidir con nada. El cambio, firmado por Miller, cabe en tres archivos. Alpine ha llevado el mismo parche a los paquetes de sus ramas estables.
## Afecta a Alpine y a otros Linux con musl sin PAM activo; Ubuntu, Debian y Red Hat quedan fuera
Según OpenSSH, el fallo no existe en los sistemas que no son Linux, en los Linux con glibc (Debian, Ubuntu, Red Hat y la mayoría de distribuciones) ni en los Linux que comprueban las contraseñas con PAM. Alpine concreta la lista: estás afectado si usas su paquete openssh-server, que se compila sin PAM, o el paquete openssh-server-pam con `UsePAM no`; si la autenticación por contraseña está activa, que es el valor por defecto de OpenSSH; si alguna cuenta tiene un asterisco en el campo de contraseña; y si al menos una cuenta local tiene un hash `$5$` o `$6$`. Están afectadas todas las versiones de Alpine que han revisado, de la 3.16 a la 3.24 y la rama edge.
No están afectados los contenedores Docker que no ejecutan sshd dentro, los sistemas con `PasswordAuthentication no`, openssh-server-pam con `UsePAM yes`, las cuentas bloqueadas con «!» en /etc/shadow (no entran ni con contraseña ni con clave), las máquinas en las que ninguna cuenta tiene un hash con `$` y las imágenes de nube configuradas con cloud-init, que escribe `PasswordAuthentication no`.
Hay un caso aparte: las imágenes tiny-cloud oficiales (qcow2, VHD y AMI) de la 3.18.11 a la 3.24.3 traen el usuario `alpine` sin contraseña y con doas sin contraseña. Son seguras en el primer arranque y pasan a ser explotables en cuanto existe un hash `$6$` en la máquina, por ejemplo cuando un administrador pone una contraseña de consola: el atacante entra como alpine y pasa a root.
## Actualizar y reiniciar sshd, o desactivar las contraseñas
Alpine pide dos cosas: actualizar (`apk upgrade -U -a`) y reiniciar sshd (`rc-service sshd restart`), porque actualizar el paquete no sustituye al demonio que ya está en marcha. Las versiones 3.21.10, 3.22.8, 3.23.8 y 3.24.4 llevan el paquete corregido, y hay paquetes para las ramas que ya no reciben actualizaciones ordinarias, hasta la 3.16; la 3.21 terminó su soporte el 1 de noviembre y aun así tiene parche.
| Rama de Alpine | openssh corregido |
| --- | --- |
| edge | 10.6\_p2-r0 |
| 3.24 | 10.3\_p1-r2 |
| 3.23 | 10.2\_p1-r1 |
| 3.22 | 10.0\_p1-r11 |
| 3.21 | 9.9\_p2-r1 |
| 3.20 | 9.7\_p1-r6 |
| 3.19 | 9.6\_p1-r3 |
| 3.18 | 9.3\_p2-r4 |
| 3.17 | 9.1\_p1-r7 |
| 3.16 | 9.0\_p1-r6 |
Si no se puede actualizar, la alternativa es desactivar el acceso por contraseña: `PasswordAuthentication no` en la configuración de sshd y reiniciar el servicio. Cualquiera de las dos medidas cierra el agujero. Alpine recomienda comprobar antes que el acceso por clave funciona y mantener la sesión abierta hasta probar una conexión nueva, y publica los comandos exactos: un archivo en `sshd_config.d`, que las versiones anteriores a la 3.19 ignoran, y un cambio sobre `sshd_config` que cubre también los bloques `Match`.
Para saber si alguien ha entrado ya, hay que buscar en /var/log/messages líneas de sshd con «Accepted password for» de cuentas que no tienen contraseña (alpine, root o cualquier usuario que solo entra con clave) y revisar el uso de doas y los usuarios, archivos y claves autorizadas creados hace poco en las máquinas expuestas. Si no se puede descartar un acceso, Alpine pide tratar la máquina como comprometida.
## Qué tiene que ver con el SEO
Un acceso no autorizado al servidor puede poner en riesgo las webs que aloja. Lo que un atacante puede hacer con ellas es lo que Google describe en sus políticas de spam como contenido hackeado: código inyectado, páginas nuevas de spam o phishing, enlaces y texto ocultos y redirecciones que solo ven algunos visitantes. En Search Console asoma en el informe de problemas de seguridad, cuando Google lo detecta. En [Los SEOs ya no podemos ignorar la ciberseguridad](https://seomanal.es/posicionamiento/los-seos-ya-no-podemos-ignorar-la-ciberseguridad/), Bruno Díaz Gonzàlez explica qué mirar en Search Console y cómo limpiar una web infectada.
Los paneles de hosting más habituales no corren sobre Alpine: cPanel solo se instala en AlmaLinux, CloudLinux, Rocky Linux y Ubuntu, y Plesk en Ubuntu, Debian y AlmaLinux, todas con glibc. El riesgo está en los servidores VPS y los contenedores montados a mano, donde Alpine es frecuente por su tamaño. Lo que toca preguntar al proveedor o al equipo de sistemas es si algún servidor o contenedor con SSH expuesto corre Alpine u otro Linux con musl, si acepta contraseñas y si se ha reiniciado sshd después de actualizar; la [guía para actualizar PHP tras PHP2Shell](https://seomanal.es/software/php-corrige-dos-fallos-criticos-como-actualizar-en-plesk-y-cpanel/) sirve de modelo para pedir al alojamiento que confirme un parche.
## OpenSSH publicará más a menudo por los informes hechos con IA
Las notas de la versión traen un aviso que va más allá de este fallo. OpenSSH dice recibir «un gran número» de informes de seguridad, muchos de ellos hallazgos de modelos de IA o hechos con su ayuda. Aunque muchos resultan no tener impacto real, el proyecto ha visto «varios casos» en los que un fallo identificado por herramientas de IA lo descubre después, de forma independiente, otro investigador, y deduce que los adversarios que no avisan también pueden encontrarlos. Por eso, de momento, publicará versiones con más frecuencia en vez de agrupar las correcciones hasta la siguiente prevista.
Miller fue más claro en la lista: han observado «múltiples casos de redescubrimiento rápido de fallos por agentes de IA, a veces en cuestión de horas», y consideran los embargos largos «una práctica peligrosa que beneficia sobre todo a los atacantes». Es lo que Díaz Gonzàlez anticipaba el 28 de octubre en su columna sobre SEO y ciberseguridad: con la IA habrá más fallos expuestos, y antes.
## Referencias
1. alpinelinux.org (2026, 5 de noviembre). *Security advisory: openssh-server password authentication bypass*. (Alpine Linux. Condiciones del ataque (257 a 1.024 bytes, cuenta con \* y otra con $5$/$6$), afectados y no afectados, imágenes tiny-cloud, versiones corregidas por rama, comandos y cómo saber si entraron.)
2. Ayuda de Google (s. f.). *Security Issues report*. (Ayuda de Search Console. El informe es la referencia para saber si Google ha detectado contenido hackeado.)
3. cve.org (2026, 5 de noviembre). *CVE-2026-123158*. (Programa CVE (MITRE). CVSS 3.1: 8,1 alta; CISA: explotación «poc»; referencias al parche, al aviso de Alpine y a sshhole.com.)
4. docs.cpanel.net (s. f.). *System Requirements*. (cPanel. Sistemas admitidos: AlmaLinux, CloudLinux, Rocky Linux y Ubuntu.)
5. docs.plesk.com (s. f.). *Plesk Obsidian: system requirements*. (Plesk. Sistemas admitidos: Ubuntu, AlmaLinux y Debian, entre otros con glibc.)
6. Google Search Central (s. f.). *Spam policies for Google web search: hacked content*. (Google Search Central. Inyección de código, de páginas y de contenido, y redirecciones.)
7. Miller, D. (2026, 5 de noviembre). *avoid password authn bypass*. GitHub. (El parche: MIN\_PASSWORD\_HASH\_LEN 4 en auth-passwd.c, no se da por válida la comparación si el campo guardado tiene menos de cuatro caracteres; tres archivos.)
8. Miller, D. (2026, 5 de noviembre). *urgent security release: 10.6p2*. marc.info. (Mensaje a la lista openssh-unix-dev: PasswordAuthentication=no o desactivar SSH «INMEDIATAMENTE»; supieron del fallo el día anterior; los agentes de IA redescubren fallos en horas.)
9. OpenSSH (2026, 5 de noviembre). *OpenSSH 10.6p2 release notes*. (fuente principal)
10. sshhole.com (2026, 5 de noviembre). *\*sshole*. (Página del hallazgo, referencia de exploit en el CVE: cronología del asterisco (1980), el \* en vez de NULL y el tope de 256 bytes en musl (2012) y la sal prestada de OpenSSH (2016, CVE-2016-6210).)
11. Tov Bustan, M. S. (2026, 5 de noviembre). *OpenSSH Password Authentication Bypass on Alpine Linux (\*sshole) – CVE-2026-123158*. ox.security. (OX Security. Explicación paso a paso de la comparación de asteriscos y lista de no afectados (glibc, PAM, Dropbear, OpenBSD).)