Si administras un servidor Alpine Linux accesible por SSH, revisa su configuración y actualiza OpenSSH. Una vulnerabilidad divulgada el 5 de noviembre permite, bajo condiciones concretas, entrar en ciertas cuentas sin conocer una contraseña válida. El problema se conoce como SSHhole y se identifica como CVE-2026-123158.
No afecta a todas las máquinas que usan SSH ni a todas las imágenes de Alpine. El riesgo aparece por la combinación de OpenSSH, la biblioteca musl, autenticación sin PAM y una configuración específica de cuentas. La advertencia de Alpine detalla las condiciones y recomienda actualizar el paquete y reiniciar el servicio.
Cuándo hay exposición
Según Alpine, deben coincidir estas condiciones en la configuración descrita por su aviso:
- El servidor
sshdes accesible para quien intenta conectarse y utiliza el paquete Alpineopenssh-serversin PAM, oopenssh-server-pamconUsePAM no. - La autenticación por contraseña está habilitada mediante
PasswordAuthentication yes. - Existe una cuenta que puede acceder y cuyo campo de contraseña es
*, situación habitual en algunas cuentas configuradas para usar claves. - Al menos otra cuenta local tiene una contraseña almacenada con un hash
$5$o$6$.
Un atacante necesita conocer el nombre de la cuenta objetivo. Alpine advierte de que, en determinadas imágenes oficiales tiny-cloud, la cuenta alpine dispone además de doas sin contraseña: si se cumplen los requisitos del fallo, el acceso a esa cuenta puede dar paso a privilegios de administrador.
El valor * no es intercambiable con cualquier marca de bloqueo: el aviso distingue las cuentas con !. También señala que un contenedor basado en Alpine no está afectado por esta vía si no ejecuta sshd dentro. Debian y Ubuntu convencionales usan glibc en lugar de musl, por lo que no encajan en el escenario descrito; comprueba igualmente los avisos del proveedor de cualquier dispositivo o distribución personalizada.
Por qué falla
Cuando OpenSSH comprueba una contraseña sin PAM, utiliza crypt() para compararla con el campo almacenado. En la combinación afectada, musl devuelve * como indicador de error ante una contraseña demasiado larga. Si ese mismo carácter aparece en el campo de la cuenta, una comparación puede interpretarlo como coincidencia.
El investigador Özgün Kültekin comunicó el fallo a los responsables de OpenSSH. La versión portátil 10.6p2, publicada el 5 de noviembre, incorpora una corrección para impedir esta vía. El mecanismo descrito afecta a la autenticación por contraseña; no significa que una clave SSH se haya roto o filtrado.
Actualizar Alpine
Alpine ha publicado paquetes corregidos en las ramas recogidas en su aviso, incluidos parches adaptados a versiones anteriores de OpenSSH. Por eso, no basta con exigir que todos los paquetes muestren 10.6p2: compara la versión instalada con la tabla de tu rama y sigue la guía de tu proveedor.
El aviso de Alpine propone actualizar los paquetes y reiniciar sshd; instalar el paquete no reemplaza el proceso que sigue ejecutándose. Antes de actuar en remoto, conserva una sesión abierta y asegúrate de contar con acceso de recuperación. Tras reiniciar, comprueba desde una segunda sesión que puedes acceder y que el servicio está usando la configuración esperada.
Si todavía no puedes actualizar, Alpine recomienda deshabilitar la autenticación por contraseña con PasswordAuthentication no y reiniciar sshd. Comprueba antes que el acceso por clave funciona y mantén la sesión actual abierta hasta probar una conexión nueva. Revisa también las directivas Match y archivos incluidos: una configuración distinta para un usuario o dirección puede cambiar el resultado. El aviso oficial incluye pasos y advertencias para ramas antiguas.
Revisar posibles accesos
Si un servidor vulnerable estuvo expuesto, actualizar cierra esta vía pero no aclara si alguien entró antes. Alpine recomienda revisar los registros de sshd en busca de accesos aceptados por contraseña a cuentas que no deberían tenerla, así como el uso de doas, usuarios creados, archivos y claves autorizadas recientes.
La ausencia de una línea en un registro no demuestra por sí sola que no haya habido acceso: depende de qué se registró y conservó. Si no puedes descartar una intrusión, sigue la recomendación de Alpine de tratar el equipo como comprometido e investigar desde un entorno de confianza.