El projecte OpenSSH va publicar el 5 de novembre la versió 10.6p2 per corregir CVE-2026-123158, conegut com a «sshole». La fallada permet iniciar sessió per SSH sense conèixer la contrasenya en sistemes Linux compilats amb la biblioteca musl i sense PAM, que és justament la configuració per defecte d'Alpine Linux. Té una puntuació CVSS 3.1 de 8,1 (alta) i ja hi ha proves de concepte públiques.
Convé deixar clar l'abast des del principi: no afecta Debian, Ubuntu, Fedora ni altres distribucions basades en glibc, ni sistemes que validen contrasenyes amb PAM, ni Dropbear o OpenBSD. Però Alpine és la base d'una quantitat enorme d'imatges Docker, routers i dispositius encastats, així que el nombre d'equips exposats no és petit.
Què ha passat
- 5 de novembre: Damien Miller anuncia OpenSSH 10.6p2 a la llista oss-security amb una «correcció de seguretat crítica» per a sistemes Linux amb musl i PAM desactivat. La fallada la va descobrir Özgün Kültekin, de Wakefield.
- 5 de novembre: Alpine publica paquets corregits per a totes les branques amb suport, des de la 3.16 fins a edge, i els detalls tècnics es fan públics.
- 6 de novembre: el GovCERT de Hong Kong emet una alerta d'amenaça alta i indica que ja circula codi de prova de concepte.
Com funciona
A Linux, els comptes que no han d'acceptar contrasenya (per exemple, un usuari que només entra amb clau SSH) solen tenir un * al camp de la contrasenya de /etc/shadow. Quan la funció crypt() de musl rep una contrasenya de més de 256 bytes, la rebutja retornant precisament *. OpenSSH, en el seu camí sense PAM, comparava aquest resultat amb el que hi ha a /etc/shadow… i com que tots dos són *, donava la contrasenya per bona.
Resultat: qualsevol contrasenya de més de 256 caràcters obre la porta dels comptes «sense contrasenya». El mateix equip d'OpenSSH considera que l'arrel del problema és fora de sshd, però com que s'explota a través seu, l'ha corregit allà: la versió 10.6p2 rebutja els hashos desats que són massa curts per ser vàlids.
A qui afecta
Segons les anàlisis d'OX Security, SAFE Security i Help Net Security, un equip és vulnerable només si es compleixen totes aquestes condicions:
- OpenSSH anterior a 10.6p2 compilat amb musl (Alpine, OpenWrt, Buildroot, Yocto i moltes imatges Docker).
- Sense PAM (el paquet
openssh-serverd'Alpine no l'usa per defecte) i amb l'accés per contrasenya activat, que és l'opció per defecte d'OpenSSH. - Un compte amb
*com a contrasenya i, a més, un altre compte local amb una contrasenya real.
Els comptes en risc són els que «mai» haurien d'acceptar contrasenya: usuaris de desplegament que només fan servir claus, usuaris LDAP o el mateix root, que a Alpine té * des de la versió 3.16 (tot i que l'opció per defecte PermitRootLogin impedeix entrar com a root si no s'ha canviat). El cas més delicat són les imatges oficials d'Alpine per a AWS i Azure, l'usuari alpine de les quals pot fer servir doas sense contrasenya: si el sistema és vulnerable, això equival a accés d'administrador. Els comptes bloquejats amb ! en lloc de * no estan afectats.
S'està explotant?
Aquí les fonts no coincideixen, així que val més ser prudent amb els titulars. L'empresa Previdian assegura que va detectar intents menys de nou hores després de la publicació i que un atacant va aconseguir accés root en un dels seus esquers amb Alpine. SAFE Security, en canvi, afirmava el 6 de novembre que no s'havia confirmat explotació real, i CISA encara no l'ha afegit al seu catàleg de vulnerabilitats explotades. El que sí que confirmen diverses fonts és que hi ha proves de concepte a GitHub; Previdian adverteix que no estan verificades i podrien contenir codi maliciós, així que no convé executar-les.
Què cal fer ja
- Actualitzar: a Alpine,
apk upgrade -U -ai desprésrc-service sshd restart. Instal·lar el paquet no reinicia el sshd que ja està en marxa; sense el reinici, continues sent vulnerable. - Comprovar la versió del paquet: corregides a partir de
10.6_p2-r0(edge),10.3_p1-r2(3.24),10.2_p1-r1(3.23),10.0_p1-r11(3.22),9.9_p2-r1(3.21),9.7_p1-r6(3.20) i9.6_p1-r3(3.19). - Si encara no pots actualitzar: desactiva l'accés per contrasenya. És la mesura que recomanen tant l'avís d'oss-security com el mateix Damien Miller:
echo "PasswordAuthentication no" > /etc/ssh/sshd_config.d/00-no-passwords.conf, comprova la configuració ambsshd -ti reinicia sshd. - Reconstruir imatges Docker: un contenidor basat en una imatge Alpine antiga amb SSH no es corregeix sol. Cal reconstruir-lo sobre la imatge actualitzada.
- Revisar els registres: busca línies
Accepted password fora/var/log/messagesper a comptes que no haurien de tenir contrasenya. Qualsevol coincidència s'ha de tractar com un compromís. - No exposar SSH a Internet si no cal: millor darrere d'una VPN o limitat per tallafocs a les xarxes d'administració.
Què cal vigilar a continuació
- Si CISA l'incorpora al catàleg KEV, cosa que confirmaria l'explotació real.
- Les actualitzacions d'imatges Docker, firmware de routers i dispositius encastats basats en musl, que solen trigar més que les distribucions.
- La fitxa definitiva del NVD, que avui encara està pendent d'anàlisi.
No és l'únic ensurt recent en servidors web: repassa PHP2Shell, les dues fallades crítiques del nucli de PHP.
Conclusió: sshole no és una fallada universal de SSH, però a Alpine és de les que no admeten espera: n'hi ha prou amb una contrasenya llarga per entrar en comptes que se suposaven tancats. Actualitzar, reiniciar sshd i, millor encara, deixar l'accés només per clau tanca el problema.
Fonts i documentació
- OpenSSH — Notes de la versió 10.6p2
- oss-security — Announce: Portable OpenSSH 10.6p2 released (Damien Miller)
- oss-security — "sshole": password authentication bypass: OpenSSH + musl libc
- Alpine Linux Security Tracker — CVE-2026-123158
- GovCERT.HK — High Threat Security Alert (A26-11-09): Vulnerability in OpenSSH
- OX Security — OpenSSH Password Authentication Bypass on Alpine Linux (*sshole)
- SAFE Security — SSHole: High-Severity OpenSSH Vulnerability
- Help Net Security — OpenSSH flaw exploited in the wild just hours after disclosure