OpenSSH en Alpine Linux: fallo deja entrar sin contraseña

OpenSSH y Alpine Linux publicaron el 5 de noviembre de 2026 la corrección de un fallo que permite entrar por SSH sin conocer la contraseña en algunos servidores Linux con la biblioteca musl y sin PAM, el caso típico de Alpine. Solo es explotable si se cumplen varias condiciones a la vez. Las imágenes Docker de Alpine sin servidor SSH no están afectadas.

Lo que se sabe

  • Qué es: según el aviso de Alpine, alguien que alcance el puerto SSH puede iniciar sesión sin saber ninguna contraseña. Las notas de OpenSSH 10.6p2 lo describen como una forma de saltarse la autenticación por contraseña en sshd que afecta a algunos Linux con musl que ejecutan sshd sin soporte de PAM.
  • De dónde viene: según las notas de OpenSSH, el origen está fuera de sshd (en la biblioteca del sistema), pero se puede explotar a través de él y se corrige en sshd.
  • Cuándo se cumple (todo a la vez, según Alpine):

- el servidor usa el paquete `openssh-server` (sin PAM) u `openssh-server-pam` con `UsePAM no`;

- `PasswordAuthentication` está en `yes`, el valor por defecto;

- existe una cuenta sin contraseña, con `*` en su campo de contraseña (por ejemplo, usuarios creados con `adduser` sin clave, o el usuario `alpine` de las imágenes cloud);

- y hay al menos otra cuenta local con contraseña.

  • Ramas afectadas: Alpine 3.16 a 3.24 y edge.
  • Versiones corregidas del paquete `openssh` (aviso de Alpine): 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. Las versiones de punto 3.21.10, 3.22.8, 3.23.8 y 3.24.4 ya los traen.
  • Imágenes cloud de Alpine: según el aviso, las imágenes oficiales tiny-cloud (qcow2, VHD y AMI) de 3.18.11 a 3.24.3 traen el usuario `alpine` sin contraseña y con permiso para hacerse root. Son seguras en el primer arranque, pero pasan a ser explotables en cuanto la máquina tiene cualquier cuenta con contraseña.
  • Qué no está afectado (según Alpine): contenedores Docker que no ejecutan sshd, servidores con `PasswordAuthentication no`, `openssh-server-pam` con `UsePAM yes`, cuentas bloqueadas y máquinas sin ninguna cuenta con contraseña. Según The Hacker News, tampoco afecta a los Linux con glibc, como Debian o Ubuntu.
  • Quién lo encontró: Özgün Kültekin, de Wakefield, según Alpine y OpenSSH. Al publicarse no tenía número CVE.

Qué cambia y qué no

  • Cambia para cualquier VPS o máquina virtual con Alpine que acepte contraseñas por SSH: hasta actualizar, una cuenta pensada para entrar solo con clave puede servir de puerta.
  • No cambia nada para quien entra solo con clave SSH y tiene `PasswordAuthentication no`.
  • No afecta a la web en sí (WordPress, Drupal o tu aplicación) ni a la mayoría de los contenedores Docker basados en Alpine, que no ejecutan un servidor SSH: el riesgo está en el acceso al servidor.

Cómo saber si te afecta

Si tienes un VPS o un servidor con Alpine:

  1. Mira la rama: `cat /etc/alpine-release`.
  2. Mira la versión del paquete, no la de OpenSSH: con `apk info -v openssh-server` (o `openssh-server-pam`) y compárala con la lista de arriba. En las ramas estables la corrección va dentro de versiones antiguas de OpenSSH, así que `ssh -V` no te dice si estás protegido.
  3. Actualiza y reinicia sshd. Alpine indica `apk upgrade -U -a` seguido de `rc-service sshd restart`: actualizar el paquete no reinicia el sshd que ya está corriendo.
  4. Si no puedes actualizar hoy, Alpine propone desactivar el acceso por contraseña (`PasswordAuthentication no`). Antes, comprueba que entras con tu clave y no cierres la sesión abierta hasta verificar que funciona.
  5. Revisa si alguien entró: Alpine aconseja buscar en `/var/log/messages` líneas «Accepted password for» de cuentas que no deberían entrar con contraseña, y revisar usuarios nuevos y archivos `authorized_keys`.

Si usas imágenes cloud de Alpine (por ejemplo, en AWS): las instancias creadas desde imágenes anteriores a 3.21.10, 3.22.8, 3.23.8 o 3.24.4 no se corrigen solas; hay que actualizar cada una o desactivar el acceso por contraseña.

Si tu web corre en contenedores Docker basados en Alpine (imágenes `-alpine` de nginx, PHP o Node.js): si el contenedor no ejecuta sshd, no te afecta según Alpine. Igual conviene reconstruir las imágenes con la base actualizada.

Si tu web está en un hosting compartido: no te toca a ti. Si quieres confirmarlo, pregunta a tu proveedor: «¿Algún servidor con acceso SSH usa Alpine Linux? ¿Ya tiene el paquete openssh corregido del 5 de noviembre?».

Si tu servidor usa Debian o Ubuntu: según The Hacker News, este fallo no te afecta, aunque esta semana sí hubo una corrección importante en su gestor de paquetes.

Relacionado: Fallo crítico en APT de Debian y Ubuntu: qué hacer hoy

Fuentes

Actualizaciones: si se asigna un CVE o se confirman ataques, se añadirá aquí con su enlace.