Los equipos de sistemas que gestionan flotas de servidores y contenedores ya tienen una forma abierta y gratuita de inventariar su exposición a SSHHole (CVE-2026-123158): SSHamble, el escáner de servicios SSH de runZero, incorpora desde la versión v0.5.1, publicada el 05/11/2026, la comprobación vuln-sshhole. La novedad coincide con la corrección del fallo en Alpine Linux y plantea un problema de inventario: saber qué máquinas, imágenes y bastiones ejecutan realmente un servidor SSH.
Las claves de la revisión de SSHHole en flotas cloud en 30 segundos
- SSHamble, escáner abierto de runZero con licencia BSD, añade la comprobación vuln-sshhole en su versión v0.5.1 del 05/11/2026.
- SSHHole afecta a OpenSSH anterior a 10.6p2 compilado con musl y sin PAM, en cuentas con asterisco en lugar de contraseña.
- Alpine ya lo ha corregido de la rama 3.16 a edge; mientras se actualiza, propone desactivar las contraseñas.
- El riesgo en contenedores se concentra en imágenes que añaden openssh-server, como bastiones, SFTP o agentes de CI.
El detalle práctico de la herramienta lo ha publicado OpenSecurity en su guía para comprobar con SSHamble si un servidor está expuesto a SSHHole. Aquí interesa cómo encaja esa comprobación en una infraestructura que mezcla nubes públicas, servidores on-premise, clústeres de Kubernetes y registries de imágenes.
El fallo exige que coincidan varias condiciones: OpenSSH (la implementación más extendida del protocolo SSH, Secure Shell) en una versión anterior a la 10.6p2, compilado con musl, la biblioteca estándar de C ligera que usa Alpine, y sin PAM (Pluggable Authentication Modules, el sistema modular de autenticación de Linux), además de cuentas con un asterisco en el campo de contraseña. Las distribuciones basadas en glibc, como Debian o Ubuntu, quedan fuera. La mitigación inmediata que propone Alpine mientras se actualiza es desactivar el acceso por contraseña con PasswordAuthentication no.
Dónde puede esconderse un sshd con musl en una flota cloud
La imagen oficial alpine de Docker Hub se describe como una imagen mínima basada en Alpine Linux, de unos 5 MB, construida sobre musl y BusyBox, y su documentación no menciona openssh ni sshd entre lo que incluye. Lo habitual es que un contenedor basado en alpine a secas no ejecute un servidor SSH, aunque conviene comprobarlo: el riesgo está en las imágenes que lo añaden con apk add openssh-server.
Ese patrón aparece en imágenes de bastión para entrar en redes privadas, en servidores SFTP para intercambio de ficheros con clientes o proveedores, en agentes y ejecutores de integración continua (CI) que reciben trabajos por SSH y en contenedores de depuración que alguien dejó desplegados. Son piezas pequeñas que no siempre figuran en el inventario principal.
Localizar imágenes con openssh y musl en los registries
En contenedores, el escaneo de red no basta: una imagen vulnerable puede esperar en el registry hasta el siguiente escalado. Según su documentación, Trivy detecta los paquetes instalados con apk en imágenes Alpine y usa los avisos de seguridad de la propia distribución, y con trivy k8s puede conectarse a un clúster de Kubernetes y analizar también las imágenes de sus cargas de trabajo, con salida en tabla o JSON. Grype, de Anchore, incluye Alpine entre los sistemas operativos soportados, puede descargar una imagen directamente de un registry sin necesidad de un runtime de contenedores, acepta SBOM (listas de materiales de software) en formato Syft, SPDX y CycloneDX, y ofrece salida JSON.
trivy k8s --report summary
grype registry:registro.ejemplo.com/bastion:latest -o jsonCon esos informes, el equipo puede filtrar las imágenes que contienen el paquete openssh-server o openssh sobre Alpine y cruzarlas con las ramas corregidas. Que la base de datos de cada escáner ya refleje CVE-2026-123158 depende de su ciclo de actualización, así que el inventario de paquetes es útil por sí mismo aunque la vulnerabilidad todavía no aparezca marcada. La corrección pasa por reconstruir la imagen y volver a desplegarla; actualizar el anfitrión no cambia nada dentro de ella. La revista ya analizó las diferencias entre Grype, Trivy y otras herramientas de escaneo de contenedores y por qué las imágenes mínimas reducen la superficie de ataque.
SSHamble como inventario de exposiciones SSH
Los escáneres de imágenes responden a qué hay dentro de cada artefacto; SSHamble responde a qué está escuchando de verdad en la red. runZero lo presentó en Black Hat USA 2024, en una investigación de HD Moore y Rob King sobre exposiciones en implementaciones SSH, y lo publicó con licencia BSD de 2 cláusulas. Recorre rangos de direcciones, identifica los servicios SSH y les aplica una batería de comprobaciones conocidas, con resultados en JSONL (JSON Lines, un objeto JSON por línea) que se pueden procesar con jq o cargar en otra herramienta de inventario.
El ejemplo que recoge la guía de OpenSecurity limita el escaneo a esta prueba sobre una red de laboratorio:
sshamble scan -u root,alpine,nobody -p 22 --checks vuln-sshhole -o resultados.jsonl 192.168.1.0/24En entornos cloud, la utilidad depende de lanzar el escaneo desde dentro de cada red: subredes privadas de las VPC (nubes privadas virtuales), segmentos de gestión on-premise y redes de nodos de Kubernetes, además de los rangos públicos propios. Solo debe usarse sobre sistemas propios o con autorización escrita, y conviene avisar antes a los equipos de sistemas y seguridad, porque los intentos de autenticación quedan registrados y pueden disparar alertas o bloqueos.
Las plataformas comerciales de gestión de vulnerabilidades y de inventario de activos suelen ofrecer paneles, correlación con la CMDB (base de datos de gestión de la configuración) y seguimiento de tickets. Una herramienta abierta como SSHamble no sustituye eso, pero permite comprobar una exposición concreta el mismo día en que se publica, auditar su código y encadenar la salida con los procesos que ya existan.
La comprobación tiene además un origen reciente y documentado. Llegó con la PR (pull request) número 53, fusionada el 05/11/2026, y sus primeros commits, firmados por Paul Asadoorian, llevan la línea «Co-Authored-By: Claude Opus 5.5», la fórmula con la que se acredita al asistente de Anthropic como coautor. El cambio pasó por la revisión del mantenedor.
Como ocurrió con el fallo de APT en Debian y Ubuntu y el parcheo de Linux en la nube, el parche ya existe y lo pendiente es el inventario: encontrar cada sshd con musl y actualizarlo o reconstruir su imagen.
Preguntas frecuentes
¿Están afectados todos los contenedores basados en Alpine?
No. La imagen oficial de Alpine en Docker Hub no menciona sshd entre su contenido; el riesgo se concentra en las imágenes que instalan openssh-server, como bastiones, servidores SFTP o agentes de CI, y que aceptan contraseñas.
¿Qué versión de SSHamble incluye la comprobación de SSHHole?
La versión v0.5.1, publicada el 05/11/2026, incluye la comprobación vuln-sshhole y genera los resultados en formato JSONL.
¿Sirven Trivy o Grype para encontrar imágenes con OpenSSH?
Ambos documentan soporte para Alpine y listan los paquetes instalados con apk, de modo que permiten localizar imágenes con openssh. Trivy puede además analizar las imágenes de un clúster de Kubernetes con trivy k8s.
¿Qué hacer si no se puede actualizar de inmediato?
Alpine propone desactivar el acceso por contraseña con PasswordAuthentication no y reiniciar sshd, tras comprobar que el acceso con clave funciona. En contenedores, la solución definitiva es reconstruir la imagen con el paquete corregido.
Fuentes:
- OpenSecurity: Cómo comprobar con SSHamble si un servidor SSH está expuesto a SSHHole
- Repositorio de SSHamble en GitHub (runZeroInc/sshamble)
- Release v0.5.1 de SSHamble
- runZero: investigación sobre exposiciones en SSH
- Alpine Linux: aviso de seguridad sobre openssh-server
- Docker Hub: imagen oficial alpine
- Trivy: cobertura de Alpine Linux
- Trivy: escaneo de Kubernetes
- Grype (Anchore) en GitHub
