CVE-2026-123158 en OpenSSH: qué revisar si usas Alpine Linux

El 5 de noviembre de 2026 se publicó OpenSSH 10.6p2, que corrige la vulnerabilidad CVE-2026-123158, apodada «sshole». Es un fallo lógico en la comprobación de contraseñas que permite a un atacante entrar por SSH en una cuenta que solo debería aceptar claves, sin conocer ninguna contraseña. No afecta a cualquier servidor: solo a los que ejecutan sshd compilado con la biblioteca musl y sin PAM, que es la configuración habitual de Alpine Linux y de muchas imágenes de contenedor basadas en Alpine. Alpine publicó paquetes corregidos ese mismo día para todas sus ramas desde la 3.16.

Qué ha pasado

El fallo lo descubrió Özgün Kültekin y tiene una puntuación CVSS 3.1 de 8,1 (alta). Nace de la combinación de dos piezas: la forma en que OpenSSH, cuando no usa PAM, toma prestada la «sal» de otra cuenta para comprobar contraseñas, y el comportamiento de la función crypt() de musl ante contraseñas muy largas. El resultado es que, en determinadas cuentas, una contraseña de más de 256 caracteres puede darse por buena. Según TuxCare, el comportamiento existe desde OpenSSH 7.3, de 2016, y llega hasta la 10.6p1.

Hay pruebas de concepto públicas, así que cabe esperar escaneos. StepSecurity no tenía constancia de explotación real a 6 de noviembre, pero Tech Insider informa de que la agencia estadounidense CISA añadió el fallo el 9 de noviembre a su catálogo de vulnerabilidades explotadas (KEV), con plazo de corrección para la administración federal de EE. UU. hasta el 12 de noviembre. Nosotros no hemos podido consultar directamente la nota de CISA; en cualquier caso, conviene actuar como si se estuviera explotando.

A quién afecta y a quién no

Para que un equipo sea vulnerable tienen que darse a la vez varias condiciones:

• sshd está enlazado con musl libc (Alpine, algunas imágenes mínimas, OpenWrt con OpenSSH instalado, sistemas embebidos hechos con Buildroot o Yocto con musl).
• sshd no usa PAM (UsePAM no o un paquete compilado sin PAM, como el openssh-server estándar de Alpine).
• PasswordAuthentication está activado, que es el valor por defecto.
• Hay una cuenta con acceso SSH cuyo campo de contraseña en /etc/shadow es * (cuentas pensadas solo para clave).
• Existe en el sistema al menos otra cuenta con una contraseña real cifrada con SHA-256/SHA-512 o bcrypt.

No están afectados Debian, Ubuntu, Red Hat Enterprise Linux, AlmaLinux ni, en general, las distribuciones basadas en glibc. Red Hat lo confirma expresamente para sus productos. Tampoco lo están los servidores que ya tienen PasswordAuthentication no ni los que comprueban contraseñas mediante PAM.

Por qué una pyme puede tener Alpine sin saberlo

En las empresas con las que trabajamos en Gipuzkoa, Euskadi y Navarra, los servidores principales suelen ser Debian o Ubuntu, y ahí es donde normalmente corre Odoo. Esos equipos pueden estar tranquilos respecto a este fallo (otra cosa es el fallo del núcleo Linux que tratamos en CVE-2026-98432: qué revisar en Proxmox y Odoo). El riesgo está en lo que no se ve a simple vista: Alpine es la base de muchísimas imágenes Docker por su pequeño tamaño, aparece en plantillas de contenedores LXC, en ejecutores de integración continua y dentro de algunos equipos y appliances. Basta con que alguien haya añadido sshd a una de esas imágenes para depurar, y haya publicado el puerto 22, para que exista exposición.

Además, StepSecurity advierte de que el riesgo sigue vivo en las imágenes construidas o fijadas antes del 5 de noviembre: capas en caché, copias en registros internos o repositorios replicados. Una instalación nueva ya recibe el paquete corregido, pero un contenedor antiguo no se actualiza solo.

Comprobación en cinco minutos

Esta es la lista que proponemos a cualquier responsable de TI:

1. Localiza dónde hay Alpine con sshd. Revisa los contenedores LXC de tu clúster Proxmox, los hosts Docker y los ejecutores de CI. Dentro de cada uno, cat /etc/os-release indica la distribución y apk info -v openssh-server si el servidor SSH está instalado. Si usas plantillas Alpine en Proxmox, comprueba en tus propios contenedores si llevan sshd.
2. Comprueba la revisión del paquete, no la versión. sshd -V y el banner de conexión no sirven: Alpine aplica el parche sin cambiar el número de versión. Compara la salida de apk info -v openssh-server con las revisiones corregidas; por ejemplo, 10.3_p1-r2 en Alpine 3.24, 10.2_p1-r1 en 3.23 y 10.0_p1-r11 en 3.22.
3. Actualiza y reinicia. En Alpine, apk upgrade -U -a y después rc-service sshd restart: actualizar el paquete no sustituye el proceso que ya está en marcha. En contenedores, reconstruye la imagen desde una base actual en lugar de parchear dentro.
4. Desactiva la contraseña en SSH. Si no puedes actualizar ya, pon PasswordAuthentication no y comprueba con sshd -T | grep -i passwordauthentication. TuxCare avisa de que en Alpine 3.18 y anteriores no basta con un fichero en /etc/ssh/sshd_config.d: hay que tocar la configuración principal. Antes de cerrar la sesión, verifica que entras con tu clave.
5. Revisa los registros. Busca líneas Accepted password for en cuentas que solo deberían usar clave (en Alpine, en /var/log/messages), especialmente un intento fallido seguido de uno aceptado en la misma conexión. Si no puedes descartar un acceso, trata el sistema como comprometido: revisa usuarios nuevos, claves añadidas en authorized_keys y uso de doas.

Cómo lo vemos en Binovo

Este fallo es un buen recordatorio de algo que repetimos en nuestros servicios de administración de sistemas: el inventario no termina en las máquinas virtuales. Los contenedores y las imágenes también son servidores, y envejecen igual. Nuestras recomendaciones:

• Acceso SSH solo con clave en todos los equipos, sean Alpine o no. Con eso este fallo no tiene recorrido.
• Nada de sshd dentro de contenedores salvo necesidad justificada; para entrar existen pct enter en Proxmox o docker exec.
• Reconstruir periódicamente las imágenes propias y no fijar versiones de base indefinidamente.
• No exponer el puerto 22 a Internet: mejor detrás de una VPN o de un bastión.

Si gestionas un entorno Proxmox y quieres revisarlo con alguien que lo hace a diario, como partner de Proxmox en España podemos ayudarte. Si lo que te preocupa es el servidor de tu ERP, puedes consultarlo dentro de nuestro servicio de mantenimiento de Odoo. Para cualquier duda, escríbenos.

Fuentes

• TuxCare, The SSH Authentication Bypass That Lived Between OpenSSH and musl, 05/11/2026 (actualizado el 06/11/2026).
• StepSecurity, CVE-2026-123158 (*sshole): OpenSSH Password Authentication Bypass on Alpine Linux, 06/11/2026.
• Red Hat, CVE-2026-123158, noviembre de 2026.
• Tech Insider, CISA KEV Adds 4 Exploited Flaws, Nov. 12 Deadline, 10/11/2026.

Transparencia: este artículo se ha elaborado con ayuda de inteligencia artificial a partir de las fuentes citadas y ha sido revisado y validado por el equipo de Binovo antes de publicarse.