OpenSSH 10.6p2 salió el 4 de noviembre de 2026 con una corrección para un bypass de autenticación por contraseña en sshd. La falla recibió el identificador CVE-2026-123158 y, el 9 de noviembre, la CISA la incluyó en el catálogo Known Exploited Vulnerabilities, la lista de fallas con explotación confirmada. Para las agencias federales de Estados Unidos, el plazo de corrección es el 12 de noviembre.
Qué permite la falla
Según la descripción publicada en el rastreador de seguridad de Ubuntu, el sshd anterior a 10.6p2, en Linux, compilado contra musl libc y sin PAM (el módulo de autenticación que usan la mayoría de las distribuciones con glibc), no tenía una protección contra este bypass. En algunas configuraciones de cuenta, se acepta cualquier contraseña de entre 256 y 1024 caracteres. Alpine Linux es el ejemplo citado. Ubuntu le asigna prioridad alta y un CVSS 3.1 de 8,1.
El mensaje del commit que corrige el problema, firmado por Damien Miller, dice que el bypass "afecta algunas configuraciones" y que la causa raíz no está en OpenSSH, aunque el proyecto puede evitarla. El cambio rechaza hashes de contraseña almacenados con menos de cuatro caracteres y ordena la liberación de memoria en las rutinas de verificación. El 9 de noviembre entró otro commit, "harden password checking", que todavía no forma parte de ninguna versión publicada.
Quién debe revisar ahora
El riesgo está en cualquier máquina o contenedor que ejecute sshd sobre musl, sin PAM, con inicio de sesión por contraseña habilitado y accesible por red. En la práctica, eso apunta a servidores e imágenes basados en Alpine: bastiones, servidores SFTP para intercambiar archivos con clientes, contenedores de desarrollo o de soporte que alguien dejó con SSH abierto.
Ubuntu, Debian y Red Hat usan glibc por defecto. Ubuntu indica que, por eso, la instalación estándar no debería estar afectada, pero mantiene los paquetes "en evaluación" porque musl está disponible en el repositorio. Quien usa Alpine solo como imagen base de la aplicación, sin instalar openssh-server, también queda fuera de alcance.
Lo difícil es saber dónde están esos sshd. Un contenedor con SSH suele nacer como atajo de depuración y quedarse sin responsable. Si nadie mantiene esas imágenes después de la entrega, la pregunta de quién cuida el sistema cuando termina el proyecto se convierte en una búsqueda apresurada en el inventario.
Qué hacer antes del 12 de noviembre
El plazo de la CISA rige para el gobierno estadounidense, pero sirve de referencia para cualquier equipo: la explotación ya está confirmada, así que esperar a la próxima ventana de mantenimiento tiene poco sentido.
- Listar hosts e imágenes con
sshden Alpine u otra distribución musl.ssh -Vmuestra la versión;ldd $(which sshd)muestra si el binario usa musl. - Actualizar a OpenSSH 10.6p2 o al paquete corregido de la distribución, y reconstruir las imágenes de contenedor que incluyen el servidor.
- Donde la actualización no pueda salir hoy, desactivar
PasswordAuthenticationensshd_configy aceptar solo clave pública, o sacar el puerto 22 de internet. - Revisar los registros de autenticación desde antes del 4 de noviembre en busca de accesos por contraseña en cuentas que no deberían usarla. La CISA marcó esta falla con exigencia de triaje forense, lo que indica que parchear puede no bastar si ya hubo acceso.
Lo que todavía no se sabe
La descripción pública no detalla qué "configuraciones de cuenta" hacen posible el bypass, y la corrección sugiere, sin confirmarlo, que el camino son cuentas con el campo de contraseña corto o vacío. Tampoco hay información pública sobre quién explota la falla ni sobre su uso en ransomware, que la CISA registra como desconocido. El commit del 9 de noviembre indica que puede llegar otra versión con más refuerzos; conviene seguir las notas de versión de OpenSSH y los avisos de Alpine antes de dar el tema por cerrado.
Si tu empresa está evaluando algo parecido, escríbeme por LinkedIn o por WhatsApp.
