OpenSSH corrige acceso sin contraseña en Alpine Linux

OpenSSH corrige acceso sin contraseña en Alpine Linux

OpenSSH y Alpine Linux corrigen una falla de acceso sin contraseña; actualiza el paquete y reinicia sshd.

Por Humberto Toledo el 6 de noviembre del 2026 a las 9:01 am PST

✨︎ Resumen (TL;DR):

  • OpenSSH lanzó el 5 de noviembre de 2026 la versión 10.6p2 para impedir una evasión de autenticación en configuraciones específicas de Alpine Linux.
  • GitHub identifica el caso como CVE-2026-123158 y muestra una puntuación de 8.1 sobre 10, de severidad alta.
  • Alpine distribuyó paquetes corregidos para varias ramas, pero pide actualizar y reiniciar sshd para activar el cambio.

OpenSSH publicó el 5 de noviembre de 2026 la versión 10.6p2 para corregir una falla que puede permitir el acceso remoto a ciertas cuentas de Alpine Linux sin conocer una contraseña. El problema aparece cuando coinciden ajustes específicos de sshd, la autenticación y las cuentas locales.

Alpine ya distribuyó paquetes corregidos, incluidos algunos para ramas antiguas. Instalar el paquete no basta: el administrador también debe reiniciar el servicio SSH para que la corrección entre en funcionamiento.

La base de avisos de seguridad de GitHub identifica el caso como CVE-2026-123158 y muestra una puntuación de 8.1 sobre 10, de severidad alta. El registro figura como no revisado por GitHub. El aviso inicial de Alpine indicaba que todavía no se había asignado un identificador cuando se redactó.

Alertas protegieron el plasma tras ciberataque en Francia
Te podría interesar:
Alertas protegieron el plasma tras ciberataque en Francia
Pantalla de computadora con un mensaje de autenticación fallida
Imagen: Markus Spiske / Pexels

La falla depende de una combinación concreta

sshd es el componente de OpenSSH que acepta conexiones SSH para administrar equipos a distancia. El fallo no afecta a todas las instalaciones. Alpine describe una combinación que debe reunir estas condiciones:

  • El servidor usa el paquete openssh-server sin PAM o tiene PAM desactivado.
  • La autenticación mediante contraseña está habilitada.
  • Existe una cuenta cuyo campo de contraseña indica que no tiene una establecida.
  • Hay al menos otra cuenta local con una contraseña almacenada en uno de los formatos señalados por el proyecto.
  • La persona que intenta entrar puede alcanzar el servicio por la red.

En sus pruebas, Check Point encontró una condición adicional: la otra cuenta local, la que tiene la contraseña almacenada, debía estar activa. Tener un valor guardado no bastó por sí solo.

La distinción cambia el riesgo para quienes usan claves SSH. Una cuenta puede estar configurada para entrar mediante una clave y no tener contraseña propia, mientras el servidor sigue aceptando intentos por contraseña. Si se cumplen las demás condiciones, esa cuenta puede quedar expuesta.

PAM es una interfaz que los sistemas pueden usar para gestionar la autenticación. El problema surge de cómo OpenSSH interpreta una respuesta de la biblioteca musl al verificar determinadas contraseñas muy largas.

Los sistemas con la autenticación por contraseña deshabilitada o que usan PAM para esas comprobaciones no reúnen la configuración descrita en el aviso. Alpine también aclara que los contenedores basados en Alpine que no ejecutan sshd no están afectados por esta vía.

Las imágenes de nube dependen de la configuración

Alpine revisó las versiones de la distribución desde la rama 3.16 hasta la 3.24, además de edge. Todas las versiones examinadas estaban afectadas antes de recibir la corrección si cumplían los requisitos de configuración.

El proyecto mencionó como ejemplo algunas imágenes oficiales de nube creadas con tiny-cloud. Esas imágenes incluyen una cuenta que, en determinadas circunstancias, puede obtener privilegios de administrador. Alpine explicó que no son vulnerables por esta vía durante el primer arranque, pero pueden quedar expuestas después si existe otra cuenta local con una contraseña almacenada en un formato compatible y se cumplen las demás condiciones.

La cuenta root, que tiene los mayores privilegios del sistema, cuenta con protección frente al acceso directo por contraseña en la configuración predeterminada de OpenSSH. Esa protección no elimina el riesgo de que otra cuenta expuesta pueda elevar sus privilegios.

Paquetes corregidos por rama de Alpine

OpenSSH publicó la versión 10.6p2, pero Alpine incorporó la solución en paquetes con números anteriores para sus ramas estables. Por eso, comparar únicamente el número general de OpenSSH con 10.6p2 puede hacer pensar que una instalación corregida todavía está sin parchear.

Rama de Alpine Paquete openssh corregido
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

Alpine también indicó que las versiones 3.21.10, 3.22.8, 3.23.8 y 3.24.4 incluyen el paquete corregido.

La distribución publicó parches hasta la rama 3.16, aunque la 3.21 y las anteriores ya no reciben soporte regular. Tener esta corrección no restablece ese soporte.

Actualizar el paquete no es el último paso

Para aplicar la solución en un sistema en funcionamiento, Alpine recomienda:

  • Actualizar el paquete correspondiente a la rama instalada.
  • Reiniciar sshd después de la actualización.
  • Si no es posible actualizar de inmediato, desactivar la autenticación por contraseña y reiniciar el servicio.

Antes de cambiar esa configuración, el proyecto aconseja comprobar que el acceso mediante clave funciona. También pide mantener abierta la sesión actual hasta verificar una nueva conexión, para evitar perder el acceso al equipo.

Revisar si hubo acceso previo

Alpine recomienda revisar los registros de autenticación en busca de accesos mediante contraseña a cuentas que no deberían aceptarla. También pide comprobar cambios recientes en usuarios, claves autorizadas y uso de privilegios.

Si no puede descartarse un acceso indebido, Alpine pide tratar la máquina como comprometida. Instalar el parche cierra la vía descrita, pero no resuelve por sí solo una posible intrusión anterior.

El investigador de seguridad Özgün Kültekin, de Wakefield, reportó la falla al proyecto OpenSSH. Según The Hacker News, al publicar su cobertura el 5 de noviembre no había reportes de ataques que la utilizaran. Esa ausencia no demuestra que nunca se haya explotado.

Fuentes: 1, 2, 3, 4, 5, 6

+ Temas Relacionados

Más de Tecnología

Feed