Saltar al contenido

sshole: la falla de OpenSSH en Alpine y qué hacer

sshole (CVE-2026-123158) permite entrar por SSH sin contraseña a ciertas cuentas en Alpine y otros sistemas con musl. A quién afecta y cómo corregirla.

Una falla de OpenSSH permite entrar sin conocer la contraseña a ciertas cuentas en Alpine Linux y otros sistemas con musl. Afecta a pocos sistemas, pero a esos les urge actualizar. Estado público al 6 de noviembre de 2026.

Qué pasó

Está registrada como CVE-2026-123158. Tiene CVSS 8,1 (alta), asignado por MITRE; NIST aún no publica su propia evaluación. La reportó Özgün Kültekin, de Wakefield, y OpenSSH 10.6p2 la corrigió el 5 de noviembre.

Damien Miller, de OpenSSH, pidió actuar de inmediato en los sistemas afectados. El proyecto considera que la causa está fuera de OpenSSH, pero agregó la defensa en `sshd` porque es por ahí donde se puede explotar.

No es una de las 948 fallas de OpenAI. Esta semana también se publicó ese estudio, sobre el kernel de Linux, y es otra noticia: la explicamos en OpenAI y las 948 fallas del kernel de Linux.

Cómo funciona. Muchas cuentas sin contraseña utilizable, como las que solo entran con llave, tienen un `` en `/etc/shadow`. Según el aviso de Alpine y el texto de su descubridor, en sistemas con la biblioteca musl una contraseña demasiado larga hace que la función de cifrado devuelva también un ``. Las dos marcas coinciden y `sshd` acepta el ingreso.

A quién afecta

Tienen que darse todas estas condiciones, según Alpine:

  • OpenSSH sobre musl y sin PAM. El paquete `openssh-server` de Alpine viene así.
  • `PasswordAuthentication` activo, que es el valor por defecto.
  • Una cuenta con `*` en su contraseña.
  • Otra cuenta local con una contraseña real (hash `$5$` o `$6$`).

Quién queda fuera. Linux con glibc, como Debian, Ubuntu o Fedora; los sistemas que usan PAM para contraseñas; y los que no son Linux, según Miller. Alpine agrega los equipos con `PasswordAuthentication no`, los contenedores que no corren `sshd`, las cuentas bloqueadas con `!` y los sistemas donde ninguna cuenta tiene un hash `$`. En Alpine, `openssh-server-pam` solo queda fuera con `UsePAM yes`: con `UsePAM no` sí está afectado.

Dónde mirar. Además de Alpine, el descubridor menciona OpenWrt, Buildroot, Yocto y muchas imágenes Docker. Una imagen solo importa si el contenedor corre `sshd` con esa configuración.

Dos casos que conviene precisar:

  • Root. Alpine trae root con `*`, pero el valor por defecto de `PermitRootLogin` bloquea ese ingreso con contraseña. El riesgo aparece con otra cuenta que pueda convertirse en root, por ejemplo mediante `doas`.
  • Imágenes de nube de Alpine. Las imágenes oficiales tiny-cloud (qcow2, VHD y AMI), de la 3.18.11 a la 3.24.3, traen el usuario `alpine` con `doas` sin contraseña. El descubridor menciona las de AWS y Azure. Alpine aclara que son seguras al primer arranque y pasan a ser explotables cuando se agrega una contraseña a cualquier cuenta. Las configuradas con cloud-init no están afectadas, porque escribe `PasswordAuthentication no`.

¿Ya la están atacando?

Hay intentos registrados, y ningún compromiso real confirmado de forma independiente:

  • Previdian vio el primer intento unas 8 horas después de publicado el CVE. Su página muestra 5 intentos desde 3 direcciones, y advierte que eso no prueba que hayan tenido éxito.
  • Help Net Security, citando a Previdian, informa 8 intentos desde una sola dirección y acceso root en un señuelo (honeypot). Las cifras no coinciden, y puede ser por el momento de cada lectura.
  • Safe Security y SOC Prime señalan que al 6 de noviembre no se ha establecido explotación real.
  • Al revisar el catálogo de CISA el 6 de noviembre, la falla no figuraba.

Existen pruebas de concepto públicas. Previdian avisa que no están verificadas y pueden contener malware, así que no conviene ejecutarlas. Con exploits a la vista, lo prudente es actuar como si los ataques ya fueran reales.

Miller aprovechó el aviso para sostener que los embargos largos ahora favorecen a los atacantes, porque agentes de IA han redescubierto fallas en cuestión de horas. Kültekin, por su parte, dice que usó enjambres de agentes de IA en su búsqueda, sin detallar su papel.

Qué hacer

  1. Identifique dónde corre OpenSSH sobre musl: servidores Alpine, contenedores con `sshd`, equipos de red y otros aparatos.
  2. Actualice y reinicie `sshd`. Alpine advierte que actualizar el paquete no reemplaza el proceso que ya está corriendo.
  3. Reconstruya las imágenes de contenedor que traen `openssh-server`, como recomienda SOC Prime.
  4. Si no puede actualizar, configure `PasswordAuthentication no`, después de comprobar que el ingreso con llave funciona y con su sesión abierta.
  5. Revise los registros. Busque en `/var/log/messages` «Accepted password for» en cuentas sin contraseña, uso de `doas`, usuarios nuevos y cambios en `authorized_keys`. Si no puede descartar un ingreso, trate el equipo como comprometido.

Versiones corregidas en Alpine

RamaPaquete `openssh` corregido
edge10.6_p2-r0
3.2410.3_p1-r2
3.2310.2_p1-r1
3.2210.0_p1-r11
3.219.9_p2-r1
3.209.7_p1-r6
3.199.6_p1-r3
3.189.3_p2-r4
3.179.1_p1-r7
3.169.0_p1-r6

Las versiones puntuales 3.21.10, 3.22.8, 3.23.8 y 3.24.4 ya traen el paquete corregido. Fuente: aviso de Alpine, que recuerda que de la 3.16 a la 3.21 ya no tienen soporte; la 3.21 lo perdió el 1 de noviembre de 2026. Compruebe la versión del paquete y no el banner de SSH, porque las distribuciones suelen aplicar correcciones sin cambiar el número visible, como advierte SOC Prime.

Qué no sabemos

  • Cuántos equipos están expuestos: las fuentes revisadas no dan una cifra.
  • Si los intentos registrados lograron comprometer algún sistema real.

Preguntas frecuentes

¿La encontró OpenAI? No. La reportó Özgün Kültekin, de Wakefield, y no forma parte de las 948 fallas del kernel que anunció OpenAI.

¿Mi servidor Ubuntu o Debian está expuesto? Según lo publicado, no por esta vía, porque usan glibc. Sigue valiendo revisar SSH y mantenerlo actualizado.

¿Basta con usar llaves SSH? Sí, si `PasswordAuthentication` está desactivado de verdad. Revise también las reglas `Match` de su configuración.

¿Basta con actualizar el paquete? No. Hay que reiniciar `sshd` y reconstruir las imágenes de contenedor que lo traen.

Fuentes

Sigue la serie

Contacto

Si necesita revisar el acceso SSH o la actualización de los servidores de su organización, ITLab puede ayudarle. Contáctenos.

¿Necesitas a alguien que se haga cargo de tu tecnología?

Cuéntanos qué necesitas ordenar, proteger o resolver. La primera conversación no tiene costo: evaluamos si nuestro modelo te sirve y cuáles serían los siguientes pasos.

Conversemos sobre tu empresa