Hay protecciones que existen precisamente para cerrar una puerta, y este hallazgo muestra que una cerradura puede abrirse por el propio mecanismo que la sostiene. En la infraestructura de Linux, algunas cuentas se bloquean a las contraseñas para dejar pasar solo a métodos más controlados; una falla descubierta por el investigador Özgün Kültekin revela que, bajo ciertas condiciones, una cuenta así puede aceptar un intento inválido. La vulnerabilidad, bautizada *sshole y registrada como CVE-2026-123158, nace de la convergencia de decisiones tomadas en 2012, 2016 y 2022, pensadas para problemas d
Un fallo de Linux en Alpine permite entrar sin contraseña válida: el "*sshole" llevaba una década oculto
Soluciones a problemas distintos que acabaron interactuando de forma imprevista
Lo desconcertante es que la protección es lo que abre la puerta, ¿no?
Sí. Una cuenta marcada con asterisco no debería aceptar contraseñas, pero ese mismo asterisco acaba coincidiendo con el que devuelve musl como error.
Conviene precisar cuándo ocurre: con contraseñas de entre 257 y 1.024 bytes, sin PAM y con otra cuenta local con hash SHA-256 o SHA-512.
Entonces no todo Alpine es vulnerable.
No. Check Point insiste en que deben cumplirse varias condiciones a la vez, y quien desactiva contraseñas o usa PAM queda fuera.
¿Y de dónde sale el fallo?
De tres cambios de 2012, 2016 y 2022, cada uno razonable por separado, que interactuaron mal.
Esa cronología es la reconstrucción del investigador, Özgün Kültekin. Lo que está confirmado es el fallo en Alpine con OpenSSH y musl; en otras plataformas es una posibilidad, no un hecho.
¿Se está explotando ya?
Previdian dice que vio ocho intentos desde una misma IP y un acceso de administrador en un servidor señuelo.
Es el dato de una sola firma, y viene de un señuelo, no de un sistema real comprometido. No sabemos la escala de la explotación.
¿Qué debe hacer quien administre estos sistemas?
Actualizar a OpenSSH 10.6p2 o a los paquetes de Alpine y reiniciar SSH. Si no puede, desactivar contraseñas, tras probar las claves.
Il Polso
- Una cuenta diseñada para rechazar contraseñas acepta una que no es válida, y ese error silencioso convierte una defensa en una brecha.
- Alpine Linux con OpenSSH sin PAM y musl queda expuesto cuando coinciden un asterisco de bloqueo con otra cuenta que usa hash SHA-256 o SHA-512.
- Las cuentas con privilegios de administrador elevan el riesgo, y ya hay indicios de explotación: un servidor señuelo registró un acceso con privilegios de administrador.
- OpenSSH lanzó la versión 10.6p2 el 5 de noviembre y Alpine distribuyó parches; reiniciar el servicio SSH es imprescindible para que el arreglo surta efecto.
Hay protecciones que existen precisamente para cerrar una puerta, y este hallazgo muestra que una cerradura puede abrirse por el propio mecanismo que la sostiene. En la infraestructura de Linux, algunas cuentas se bloquean a las contraseñas para dejar pasar solo a métodos más controlados; una falla descubierta por el investigador Özgün Kültekin revela que, bajo ciertas condiciones, una cuenta así puede aceptar un intento inválido. La vulnerabilidad, bautizada *sshole y registrada como CVE-2026-123158, nace de la convergencia de decisiones tomadas en 2012, 2016 y 2022, pensadas para problemas distintos que terminaron encontrándose. Su corrección ya está publicada, aunque su alcance depende de cómo cada administrador haya configurado sus sistemas.
Existen cuentas de Linux que se bloquean a propósito para no aceptar contraseñas y permitir solo otros métodos de autenticación. Es una práctica sensata en entornos de acceso muy restringido. Pero una vulnerabilidad recién descubierta muestra que esa protección puede fallar en sentido contrario: una cuenta cerrada a las contraseñas termina aceptando una que no es válida.
El fallo, llamado *sshole y registrado como CVE-2026-123158, permite entrar a distancia en ciertas cuentas sin conocer la contraseña correcta. Se ha confirmado en configuraciones de Alpine Linux que combinan OpenSSH con musl y prescinden de PAM. El investigador Özgün Kültekin lo descubrió, y el 5 de noviembre OpenSSH y Alpine publicaron correcciones.
El mecanismo surge cuando OpenSSH verifica una contraseña para una cuenta que no debería aceptarlas. Al no encontrar los datos necesarios en esa cuenta, reutiliza los de otra. Si la contraseña introducida mide entre 257 y 1.024 bytes, una función de musl devuelve un asterisco como señal de error, el mismo símbolo que bloquea la cuenta protegida. El servidor interpreta que ambos valores coinciden y deja pasar al atacante. El origen se remonta a cambios de 2012, 2016 y 2022, pensados para problemas distintos que acabaron interactuando.
No todos los sistemas Alpine son vulnerables. Hacen falta varias condiciones a la vez, según Check Point, incluida una cuenta local activa con hash SHA-256 o SHA-512. El riesgo crece cuando la cuenta afectada tiene permisos elevados, como ciertas imágenes oficiales para la nube. Ya hay señales de ataque: Previdian registró ocho intentos desde una misma IP y un acceso con privilegios de administrador en un servidor señuelo.
La recomendación es actualizar a OpenSSH 10.6p2 o al parche de Alpine para cada rama, y reiniciar el servicio SSH. Quien no pueda hacerlo de inmediato debería desactivar la autenticación por contraseña, comprobando antes que el acceso con claves funciona.
Hay cuentas de Linux que se bloquean a propósito para que no acepten contraseñas y solo permitan otros métodos de autenticación. Es una práctica razonable donde el acceso debe estar muy controlado. Una vulnerabilidad recién descubierta demuestra que esa protección puede fallar justo al revés: una cuenta cerrada a las contraseñas acaba abriéndose ante una que no es válida.
El fallo se llama *sshole y tiene el identificador CVE-2026-123158. Permite entrar a distancia en determinadas cuentas de sistemas Linux sin conocer una contraseña válida. Se ha confirmado en configuraciones de Alpine Linux que combinan OpenSSH con musl, una biblioteca básica del sistema, y que prescinden de PAM, el mecanismo que gestiona la autenticación. Otras plataformas podrían verse afectadas si reúnen las mismas condiciones. Lo descubrió el investigador Özgün Kültekin, de Wakefield, y el 5 de noviembre tanto OpenSSH como Alpine publicaron correcciones.
Para entender el mecanismo hay que partir de SSH, el protocolo con el que se administra un equipo a distancia, por ejemplo un servidor al que nadie tiene acceso físico. OpenSSH es una de sus implementaciones y admite contraseñas o claves criptográficas. En Linux, el archivo /etc/shadow guarda los datos para verificar las contraseñas. Si el campo de una cuenta contiene un asterisco, la autenticación ordinaria por contraseña debería quedar bloqueada, aunque otros métodos sigan funcionando.
Según explica Kültekin, el problema aparece cuando OpenSSH comprueba una contraseña para una cuenta que no debería aceptarlas. Como no encuentra en ella los datos necesarios, usa la información de otra cuenta para hacer la verificación. Si la contraseña introducida tiene entre 257 y 1.024 bytes, la función de musl que la procesa devuelve un asterisco para señalar un error. Ese mismo símbolo figura en la cuenta protegida, así que el servidor interpreta ambos valores como coincidentes y deja pasar al atacante.
El origen está lejos en el tiempo. Según la reconstrucción del investigador, en 2012 musl cambió la forma de comunicar ciertos errores y fijó un límite de longitud al procesar contraseñas para evitar ataques de denegación de servicio. Cuatro años después, OpenSSH introdujo cambios para que nadie pudiera averiguar qué usuarios existen en un sistema midiendo tiempos de respuesta. En 2022, Alpine ajustó la configuración de su cuenta de administrador para permitir el acceso con claves SSH. Eran soluciones a problemas distintos que acabaron interactuando de forma imprevista.
Usar Alpine Linux no implica ser vulnerable. Según la firma Check Point, deben cumplirse varias condiciones a la vez: que OpenSSH funcione sin PAM, admita contraseñas y encuentre una cuenta con el asterisco. Además, tiene que existir otra cuenta local activa con un hash de contraseña generado con SHA-256 o SHA-512. Quedan fuera los sistemas que desactivan la autenticación por contraseña y los que usan PAM para gestionarla.
La gravedad sube cuando la cuenta afectada tiene permisos elevados. Alpine cita como ejemplo ciertas imágenes oficiales para la nube, donde el usuario alpine puede ejecutar comandos de administrador con doas sin contraseña. Esas imágenes son seguras en el primer arranque, pero pueden volverse vulnerables si luego se configura una cuenta con un hash compatible. Entonces un atacante podría controlar el sistema. Ya hay indicios de explotación: la firma Previdian asegura haber detectado ocho intentos desde una misma dirección IP y confirmado un acceso con privilegios de administrador en uno de sus servidores señuelo.
OpenSSH publicó el 5 de noviembre la versión 10.6p2, y Alpine distribuyó actualizaciones para varias ramas, incluidas algunas antiguas. Sus responsables advierten de que no basta con instalar el parche: hay que reiniciar el servicio SSH para que use el código corregido. Quien no pueda actualizar todavía debería desactivar la autenticación por contraseña y reiniciar el servicio, tras comprobar que el acceso con claves funciona.
Citazioni salienti
Instalar los parches no basta: también hay que reiniciar el servicio SSH para usar el código corregido.— Responsables de Alpine Linux (paráfrasis)