OpenSSH dicht beveiligingslek in sshd op musl-systemen zonder PAM

Het OpenSSH‑project heeft een ernstig lek in de SSH‑server (sshd) verholpen. Het probleem raakt Linux‑systemen die zijn gebouwd op musl libc en waarop PAM (Pluggable Authentication Modules) niet wordt gebruikt. De fix zit in OpenSSH 10.6p2, uitgebracht op 5 november 2026. Oudere versies zijn kwetsbaar. Volgens de release‑notes is in sshd een beveiligingswork‑around toegevoegd die een wachtwoord‑authenticatiebypass voorkomt op deze specifieke platforms. (openssh.org)

Wat er misging
Op musl‑gebaseerde systemen zonder PAM controleert sshd wachtwoorden met de C‑bibliotheekfunctie crypt(). Als een aanvaller een extra lang wachtwoord invoert, gaat crypt() op musl de mist in en retourneert het een asterisk (). Omdat accounts zonder wachtwoord in /etc/shadow óók een in het wachtwoordveld hebben, lijkt de controle te “kloppen” en kan de login toch slagen. Dit gebeurt alleen bij zeer lange wachtwoorden in een smalle bandbreedte: van 257 tot 1024 bytes. OpenSSH 10.6p2 omzeilt dit gedrag en voorkomt zo de bypass. (alpinelinux.org)

Wanneer ben je kwetsbaar?
Alle onderstaande voorwaarden moeten gelden:

• Het systeem draait Linux met musl libc (bijvoorbeeld Alpine Linux).
• OpenSSH is gebouwd en geconfigureerd zonder PAM.
• PasswordAuthentication staat aan.
• Er bestaat minstens één account met een als wachtwoordveld (bijv. een key‑only gebruiker) én er is ten minste één ander account met een geldige SHA‑256 of SHA‑512 hash (te herkennen aan $5$ of $6$). In dat geval kan elk wachtwoord van 257–1024 bytes de controle omzeilen voor die “”-accounts. (alpinelinux.org)

Wie níet geraakt wordt
De kwetsbaarheid is sterk configuratie‑ en platformafhankelijk. Distributies die glibc gebruiken – zoals standaard Debian en Ubuntu – vallen buiten het beschreven toepassingsgebied. Alpine Linux en andere minimal‑distribs zijn juist expliciet op musl gebouwd; Debian en Ubuntu leveren glibc standaard mee. (alpinelinux.org)

Advies en mitigaties

• Update direct: installeer OpenSSH 10.6p2 of het gedistribueerde backport‑pakket voor jouw release. Op Alpine geldt bovendien: herstart sshd na de update, anders blijft het oude proces actief. (openssh.org)
• Schakel waar mogelijk wachtwoordauthenticatie uit: zet PasswordAuthentication no en herstart sshd. Dit sluit de aanvalsvector ook op kwetsbare builds. (alpinelinux.org)
• Beperk blootstelling: bied SSH‑beheerpoorten niet openlijk aan op het internet, maar scherm af met firewalls, netwerk‑allowlists of een VPN. Gebruik sleutels en, waar passend, PAM‑gebaseerde maatregelen zoals 2FA.

Snelle zelfcheck

• Controleer of je musl gebruikt: op Alpine is dat standaard; op andere systemen geeft ldd –version “musl” of “glibc” terug. (alpinelinux.org)
• Check je sshd‑versie: ssh -V en/of dpkg/apk/rpm‑pakketversies.
• Kijk of PAM is ingeschakeld: in sshd_config moet UsePAM yes staan (en is PAM nodig in de build). Zonder PAM val je binnen de risicogroep. (openssh.org)
• Draait er een account met een * in /etc/shadow? Denk aan key‑only service‑accounts of images die zo’n account standaard meeleveren. (alpinelinux.org)

Incidentdetectie
Controleer je logs op onverwachte “Accepted password for”‑meldingen voor accounts die geen wachtwoord horen te hebben (bijvoorbeeld een key‑only gebruiker). Als je dat niet hard kunt uitsluiten, behandel het systeem dan als gecompromitteerd. (alpinelinux.org)

Achtergrond en status

• De release‑notes schrijven de kwetsbaarheid toe aan extern bibliotheekgedrag, maar benadrukken dat het via sshd te misbruiken was; 10.6p2 voorkomt dat. Onderzoekers schrijven het gedrag toe aan de manier waarop musl’s crypt() bij te lange wachtwoorden faalt. (openssh.org)
• De kwestie is inmiddels voorzien van een CVE‑verwijzing (CVE‑2026‑123158) in publieke trackers. Distributies rollen updates uit. (security-tracker.debian.org)

Kortom: draai je OpenSSH op musl zonder PAM en staan wachtwoordlogins aan, update dan onmiddellijk naar (of voorbij) 10.6p2 en zet PasswordAuthentication no. Daarmee sluit je deze specifieke bypass af en voldoe je meteen aan een best practice die breder geldt. (openssh.org)

---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ----
Opzoek naar de laatste updates uit onze securitylog?
Inhoud mede mogelijk gemaakt door OpenAI.