El fallo "SSHole" de OpenSSH (CVE-2026-123158)
Report Defense LTDA · Publicado el 12 nov 2026 · Lectura de 8 min
The OpenSSH "SSHole" Flaw (CVE-2026-123158)
Report Defense LTDA · Published Nov 12, 2026 · 8 min read
SSHole es un bypass de autenticación por contraseña en OpenSSH (versiones portables 7.3p1 a 10.6p1) cuando está enlazado con musl libc. Un atacante remoto puede iniciar sesión sin credenciales, en una sola conexión, en cuentas cuyo campo de contraseña en /etc/shadow es *. Está siendo explotado activamente y figura en el catálogo KEV de CISA. La corrección es OpenSSH 10.6p2 y reiniciar sshd.
La vulnerabilidad registrada como CVE-2026-123158 en el catálogo de MITRE, conocida coloquialmente como SSHole o *sshole, es una falla grave de autenticación en OpenSSH, no un marco ni un estándar de gestión de ciberseguridad. Aunque su divulgación pública y la asignación oficial del CVE ocurrieron el 5 de noviembre de 2026, el error se introdujo involuntariamente una década antes, en agosto de 2016, con la publicación de OpenSSH 7.3 (y Portable OpenSSH 7.3p1).
01 Origen: un parche de 2016
El cambio de código de 2016 buscaba corregir CVE-2016-6210, una vulnerabilidad de canal lateral por tiempo que permitía a un atacante remoto enumerar usuarios: midiendo cuánto tardaba el servidor en procesar el hash de la contraseña, podía distinguir entre cuentas válidas, inexistentes o sin hash configurado.
Para igualar los tiempos de respuesta, los desarrolladores obligaron al demonio de OpenSSH a ejecutar siempre una operación criptográfica completa, incluso cuando la cuenta no tenía un hash válido. Sin quererlo, sentaron las bases para una colisión con la forma en que algunas bibliotecas C alternativas señalan los errores de validación de entrada.
02 Descubrimiento y divulgación
El hallazgo, la caracterización técnica y la divulgación coordinada estuvieron a cargo del investigador Özgün Kültekin, de la organización de investigación Wakefield, que publicó el análisis el 5 de noviembre de 2026. Intervienen dos comunidades de código abierto:
- OpenSSH Project, que desarrolla y mantiene OpenSSH bajo el paraguas de OpenBSD.
- musl libc, una biblioteca C ligera y orientada a estándares, muy usada en distribuciones Linux para contenedores y sistemas embebidos.
Tras el reporte privado, el equipo de OpenSSH y los mantenedores de distribuciones —en especial el equipo de seguridad de Alpine Linux— publicaron parches coordinados el mismo 5 de noviembre. Después, NIST (a través de la NVD), MITRE, CISA y ENISA (mediante la European Vulnerability Database) catalogaron, puntuaron y emitieron directivas operativas sobre la falla.
03 Anatomía técnica
SSHole nace de la interacción inesperada de tres componentes:
- La convención Unix de
/etc/shadow: las cuentas sin contraseña usable (cuentas de servicio o administrativas que solo usan llave pública SSH) suelen guardar un único asterisco*en el campo del hash. - La lógica de verificación de contraseñas sin PAM de
sshd(auth-passwd.c). - El manejo de errores de la función
crypt()en musl libc.
*.* no es una sal válida, la lógica anti-enumeración de 2016 toma prestada la sal de otra cuenta con hash SHA-256 ($5$) o SHA-512 ($6$).crypt() de musl limita SHA-crypt a 256. Con 257–1.024 bytes, musl rechaza la entrada y devuelve "*" como indicador de error.sshd compara "*" con el campo almacenado * sin filtrar el token de error: coinciden y se concede acceso sin autenticación.04 Entornos afectados y condiciones de explotación
La falla aparece en infraestructuras cloud-native, microservicios en contenedores, pipelines de CI/CD y dispositivos de red embebidos que usan distribuciones Linux basadas en musl en lugar de la GNU C Library (glibc):
| Plataforma | Condición de exposición |
|---|---|
| Alpine Linux | Versiones 3.16 y posteriores con paquetes de OpenSSH sin parchear |
| OpenWrt | Cuando usa openssh-server en lugar de Dropbear (el servidor SSH por defecto) |
| Buildroot | Imágenes basadas en musl con OpenSSH |
| Yocto Project | Configurado con TCLIBC=musl |
Para que un sistema sea explotable deben cumplirse las cinco condiciones a la vez:
- Portable OpenSSH entre 7.3p1 y 10.6p1, enlazado con musl libc.
sshdfunciona sin PAM (UsePAM noo compilado sin soporte PAM).- La autenticación por contraseña está habilitada (
PasswordAuthentication yes, el valor por defecto). - La cuenta objetivo tiene
*en/etc/shadowy la política SSH le permite iniciar sesión. - Al menos otra cuenta (normalmente
root) tiene un hash SHA-crypt válido$5$o$6$del que tomar la sal.
05 Explotación activa
Las imágenes cloud oficiales de Alpine Linux crean un usuario alpine con * en /etc/shadow (acceso solo por llave SSH) y, a la vez, le otorgan escalamiento a root sin contraseña mediante doas.
Los atacantes empezaron a explotar exactamente esta configuración nueve horas después de la divulgación, el 6 de noviembre de 2026: enviaban contraseñas sobredimensionadas para saltarse la autenticación, escalaban a root con doas e instalaban backdoors en Python. CISA añadió CVE-2026-123158 a su catálogo Known Exploited Vulnerabilities (KEV) el 9 de noviembre de 2026, con remediación obligatoria bajo la Binding Operational Directive (BOD) 22-01.
06 La corrección: OpenSSH 10.6p2
El 5 de noviembre de 2026 se publicó OpenSSH 10.6p2. En su aviso oficial, los mantenedores señalaron que la causa raíz está fuera de sshd, en la semántica de error de la biblioteca C; aun así, añadieron una verificación defensiva en xcrypt() y auth-passwd.c que rechaza cualquier hash almacenado o devuelto de menos de cuatro caracteres, neutralizando "*" antes de cualquier comparación.
07 Clasificación y marcos de referencia
| Marco | Referencia |
|---|---|
| CVSS v3.1 | 8.1 High · AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H |
| MITRE CWE | CWE-394 (Unexpected Status Code or Return Value) · secundariamente CWE-303 (Incorrect Implementation of Authentication Algorithm) |
| NIST SP 800-53 Rev. 5 | IA-2 (Identificación y Autenticación), AC-3 (Aplicación de Acceso), SI-2 (Corrección de Fallas) |
| ISO/IEC 27001 / 27002:2022 | Control 8.8 (Gestión de vulnerabilidades técnicas) y 8.5 (Autenticación segura) |
| CIS Controls v8 | Controles 4 y 7 |
| MITRE ATT&CK | T1078 (Valid Accounts) · T1190 (Exploit Public-Facing Application) |
| CISA | Catálogo KEV (9 nov 2026) · BOD 22-01 |
08 Conceptos erróneos frecuentes
- "Cualquier servidor Linux con OpenSSH es vulnerable." Falso: las distribuciones con glibc (Debian, Ubuntu, Red Hat Enterprise Linux) y los sistemas que usan PAM no están afectados.
- "Las cuentas bloqueadas con
!también están expuestas." Falso: un campo bloqueado con!o prefijo!no puede coincidir con el valor"*"devuelto. - "Con
apk upgradebasta." Falso: actualizar el paquete no protege hasta que el procesosshden ejecución se reinicia explícitamente.
09 Recomendaciones de Report Defense
1. Identifique si sus sistemas cumplen las condiciones (ejecutar como root):
# ¿El sistema usa musl o glibc?
$ ldd --version 2>&1 | head -1
# Versión instalada de OpenSSH (Alpine)
$ apk list --installed 'openssh*'
# Configuración efectiva de sshd
$ sshd -T | grep -Ei '^(usepam|passwordauthentication)'
# Cuentas con '*' en /etc/shadow
$ awk -F: '$2=="*" {print $1}' /etc/shadow2. Actualice y reinicie el servicio:
$ apk update && apk upgrade openssh
$ rc-service sshd restart3. Mitigación temporal si no puede actualizar de inmediato: deshabilite la autenticación por contraseña y use solo llaves SSH.
# /etc/ssh/sshd_config
PasswordAuthentication no
KbdInteractiveAuthentication no4. Reconstruya imágenes de contenedores y firmware basados en musl que incluyan openssh-server; actualizar un host no corrige las imágenes ya publicadas.
5. Busque indicios de compromiso si un sistema estuvo expuesto: inicios de sesión de alpine u otras cuentas sin contraseña, uso de doas, y scripts o procesos Python desconocidos.
10 Fuentes
- OpenSSH 10.6p2 Release Notes (2026)
- Alpine Linux Security Advisories (2026)
- NIST National Vulnerability Database — CVE-2026-123158 (2026)
- CISA Known Exploited Vulnerabilities Catalog, alerta del 9 de noviembre de 2026
- Registros MITRE CVE y CWE
- Divulgación original de Özgün Kültekin, Wakefield (2026)
SSHole is a password authentication bypass in OpenSSH (Portable versions 7.3p1 through 10.6p1) when linked against musl libc. A remote attacker can log in without credentials, in a single connection, to accounts whose password field in /etc/shadow is *. It is being actively exploited and is listed in CISA's KEV catalog. The fix is OpenSSH 10.6p2 plus restarting sshd.
The vulnerability tracked under MITRE identifier CVE-2026-123158, colloquially referred to as SSHole or *sshole, is a severe authentication flaw in OpenSSH, not a cybersecurity management framework or standard. While its public disclosure and official CVE assignment occurred on November 5, 2026, the bug was inadvertently introduced a decade earlier, in August 2016, with the release of OpenSSH 7.3 (and Portable OpenSSH 7.3p1).
01 Origin: a 2016 patch
The 2016 code change was meant to fix CVE-2016-6210, a timing side-channel that allowed remote attackers to enumerate users: by measuring how long the server took to process password hashing, they could tell valid accounts apart from non-existent ones or accounts with no password hash configured.
To equalize response times, the developers forced the OpenSSH daemon to always perform a full cryptographic hashing operation, even when the account had no valid hash. Unintentionally, this laid the groundwork for a collision with how certain alternative C libraries signal input validation errors.
02 Discovery and disclosure
The discovery, technical characterization and coordinated disclosure were carried out by researcher Özgün Kültekin of the security research organization Wakefield, who published the analysis on November 5, 2026. Two open-source communities are involved:
- The OpenSSH Project, which develops and maintains OpenSSH under the umbrella of OpenBSD.
- musl libc, a lightweight, standards-focused C library widely used in container and embedded Linux distributions.
Following the private report, the OpenSSH team and distribution maintainers — most notably the Alpine Linux security team — released coordinated patches on November 5. NIST (via the NVD), MITRE, CISA and ENISA (through the European Vulnerability Database) then cataloged, scored and issued operational directives about the flaw.
03 Technical anatomy
SSHole stems from an unexpected interaction between three components:
- The Unix
/etc/shadowconvention: accounts without a usable password (service accounts or admin accounts restricted to SSH public keys) often store a single asterisk*in the hash field. - The non-PAM password verification logic in
sshd(auth-passwd.c). - The error handling of the
crypt()function in musl libc.
*.* is not a valid salt, the 2016 anti-enumeration logic borrows the salt of another account using a SHA-256 ($5$) or SHA-512 ($6$) hash.crypt() caps SHA-crypt at 256. With 257–1,024 bytes, musl rejects the input and returns "*" as an error indicator.sshd compares "*" to the stored * without filtering the error token: they match and unauthenticated access is granted.04 Affected environments and exploitation preconditions
The flaw shows up in cloud-native infrastructure, containerized microservices, CI/CD pipelines and embedded networking devices that rely on musl-based Linux distributions instead of the GNU C Library (glibc):
| Platform | Exposure condition |
|---|---|
| Alpine Linux | Versions 3.16 and later running unpatched OpenSSH packages |
| OpenWrt | When using openssh-server instead of Dropbear (the default SSH server) |
| Buildroot | musl-based images shipping OpenSSH |
| Yocto Project | Configured with TCLIBC=musl |
For a system to be exploitable, all five conditions must hold at once:
- Portable OpenSSH from 7.3p1 to 10.6p1, linked against musl libc.
sshdruns without PAM (UsePAM noor compiled without PAM support).- Password authentication is enabled (
PasswordAuthentication yes, the default). - The target account has
*in/etc/shadowand SSH policy allows it to log in. - At least one other account (commonly
root) has a valid$5$or$6$SHA-crypt hash to borrow a salt from.
05 Active exploitation
Official Alpine Linux cloud images create a default alpine user with * in /etc/shadow (SSH key-only access) while also granting it passwordless escalation to root via doas.
Threat actors began exploiting this exact configuration within nine hours of disclosure, on November 6, 2026: sending oversized passwords to bypass authentication, escalating to root via doas and deploying Python-based backdoors. CISA added CVE-2026-123158 to its Known Exploited Vulnerabilities (KEV) catalog on November 9, 2026, mandating remediation under Binding Operational Directive (BOD) 22-01.
06 The fix: OpenSSH 10.6p2
OpenSSH 10.6p2 was released on November 5, 2026. In their official advisory, the maintainers noted that the root cause lies outside sshd, in the C library's error return semantics; nevertheless, they added a defensive check in xcrypt() and auth-passwd.c that rejects any stored or returned hash shorter than four characters, neutralizing "*" before any comparison takes place.
07 Classification and frameworks
| Framework | Reference |
|---|---|
| CVSS v3.1 | 8.1 High · AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H |
| MITRE CWE | CWE-394 (Unexpected Status Code or Return Value) · secondarily CWE-303 (Incorrect Implementation of Authentication Algorithm) |
| NIST SP 800-53 Rev. 5 | IA-2 (Identification and Authentication), AC-3 (Access Enforcement), SI-2 (Flaw Remediation) |
| ISO/IEC 27001 / 27002:2022 | Control 8.8 (Management of Technical Vulnerabilities) and 8.5 (Secure Authentication) |
| CIS Controls v8 | Controls 4 and 7 |
| MITRE ATT&CK | T1078 (Valid Accounts) · T1190 (Exploit Public-Facing Application) |
| CISA | KEV Catalog (Nov 9, 2026) · BOD 22-01 |
08 Common misconceptions
- "Any Linux server running OpenSSH is vulnerable." False: glibc-based distributions (Debian, Ubuntu, Red Hat Enterprise Linux) and systems using PAM are unaffected.
- "Accounts locked with
!are exposed too." False: a field locked with!or a!prefix cannot match the returned"*"value. - "Running
apk upgradeis enough." False: updating the package does not protect you until the runningsshdprocess is explicitly restarted.
09 Report Defense recommendations
1. Identify whether your systems meet the preconditions (run as root):
# Does the system use musl or glibc?
$ ldd --version 2>&1 | head -1
# Installed OpenSSH version (Alpine)
$ apk list --installed 'openssh*'
# Effective sshd configuration
$ sshd -T | grep -Ei '^(usepam|passwordauthentication)'
# Accounts with '*' in /etc/shadow
$ awk -F: '$2=="*" {print $1}' /etc/shadow2. Update and restart the service:
$ apk update && apk upgrade openssh
$ rc-service sshd restart3. Temporary mitigation if you cannot update right away: disable password authentication and use SSH keys only.
# /etc/ssh/sshd_config
PasswordAuthentication no
KbdInteractiveAuthentication no4. Rebuild musl-based container images and firmware that ship openssh-server; updating a host does not fix images that are already published.
5. Hunt for indicators of compromise if a system was exposed: logins by alpine or other passwordless accounts, doas usage, and unknown Python scripts or processes.
10 Sources
- OpenSSH 10.6p2 Release Notes (2026)
- Alpine Linux Security Advisories (2026)
- NIST National Vulnerability Database — CVE-2026-123158 (2026)
- CISA Known Exploited Vulnerabilities Catalog alert of November 9, 2026
- MITRE CVE and CWE records
- Original disclosure by Özgün Kültekin, Wakefield (2026)