La comunidad de seguridad informática tiene un nuevo quebradero de cabeza con nombre tan llamativo como el problema que describe: *sshole. Se trata de la vulnerabilidad identificada como CVE-2026-123158, descubierta por el investigador Özgün Kültekin, que permite acceder de forma remota a determinadas cuentas de sistemas Linux sin conocer una contraseña válida. Lo curioso del caso es que el fallo no aparece en cuentas mal protegidas, sino precisamente en aquellas que fueron configuradas para bloquear el acceso mediante contraseña, utilizando un asterisco en el archivo /etc/shadow como señal de que esa vía de entrada debía quedar cerrada.
El problema se ha confirmado en instalaciones de Alpine Linux, una distribución muy popular en contenedores y entornos cloud, que combinan OpenSSH con la biblioteca musl y prescinden del sistema PAM para gestionar la autenticación. Cuando OpenSSH intenta verificar una contraseña para una cuenta sin datos válidos, termina comparando el resultado con el de otra cuenta del sistema. Si la contraseña introducida tiene entre 257 y 1.024 bytes, musl devuelve un asterisco como código de error, el mismo símbolo que debería bloquear el acceso. El servidor interpreta ambos valores como coincidentes y, sorprendentemente, deja pasar al atacante.
Lo más llamativo de esta historia es su origen: no es un error reciente, sino la suma de decisiones tomadas en momentos completamente distintos. En 2012, musl cambió la forma de reportar errores de longitud en las contraseñas para evitar ataques de denegación de servicio. En 2016, OpenSSH introdujo medidas para impedir que se pudiera detectar la existencia de usuarios midiendo tiempos de respuesta. Y en 2022, Alpine modificó la configuración de su cuenta de administrador para permitir acceso mediante claves SSH. Tres parches razonables, pensados para resolver problemas de seguridad legítimos, que una década después se combinaron para abrir una puerta trasera nunca prevista por nadie.
Para que un sistema sea vulnerable deben cumplirse varias condiciones a la vez: OpenSSH debe funcionar sin PAM, permitir autenticación por contraseña, y debe existir en el sistema otra cuenta activa con un hash generado mediante SHA-256 o SHA-512. Alpine ha puesto como ejemplo de riesgo real sus imágenes oficiales en la nube, donde el usuario ‘alpine’ puede ejecutar comandos de administrador sin contraseña mediante doas; si después se configura una cuenta vulnerable, un atacante podría llegar a tomar el control total del sistema. La firma de seguridad Previdian afirma haber detectado ya intentos de explotación activa desde una misma dirección IP, incluido un acceso exitoso con privilegios de administrador en uno de sus servidores señuelo.
La buena noticia es que ya existe solución. El 5 de noviembre, tanto OpenSSH (versión 10.6p2) como Alpine publicaron parches que corrigen el comportamiento. Eso sí, los responsables advierten de que no basta con actualizar: también hay que reiniciar el servicio SSH para que cargue el código corregido, y quienes no puedan actualizar de inmediato deberían desactivar temporalmente la autenticación por contraseña. Para la comunidad geek y de administradores de sistemas, *sshole es un recordatorio perfecto de que la seguridad informática rara vez falla por un solo error: a veces hacen falta tres decisiones correctas, tomadas en años distintos, para construir sin querer la puerta trasera perfecta.