OpenSSH 10.6p2: Passwort-Umgehung auf Alpine und anderen musl-Systemen
OpenSSH 10.6p2 vom 5. November 2026 enthält eine Abhilfe gegen einen kritischen Fehler auf Linux-Systemen mit musl und sshd ohne PAM, darunter Alpine Linux. Konten mit dem Platzhalter * im Passwortfeld akzeptieren dort beliebige überlange Passwörter. Systeme mit glibc oder PAM sind nicht betroffen, eine CVE nennen die Quellen noch nicht.
Das OpenSSH-Projekt hat am 5. November 2026 Portable OpenSSH 10.6p2 veröffentlicht. Die Version enthält laut Release-Notes eine kritische Sicherheitsabhilfe (Workaround) für Linux-Systeme, die die C-Bibliothek musl verwenden und sshd ohne PAM betreiben. Auf solchen Systemen können Angreifer sich unter bestimmten Bedingungen per Passwort an Konten anmelden, die gar kein Passwort haben sollten. Eine CVE-Nummer nennen die Quellen bisher nicht.
Wichtigster Fall ist Alpine Linux, dessen sshd-Paket laut BleepingComputer standardmäßig ohne PAM arbeitet. Debian, Ubuntu, Fedora und andere Systeme mit glibc sind nicht betroffen, ebenso Systeme mit PAM-Anmeldung und Nicht-Linux-Systeme. Wer Alpine oder andere musl-Systeme mit erreichbarem SSH-Dienst betreibt, sollte heute handeln.
Was ist passiert?
Der Fehler wurde von Özgün Kültekin (Wakefield) gemeldet. OpenSSH-Entwickler Damien Miller schrieb am 5. November, das Projekt habe am Vortag davon erfahren und veröffentliche so schnell wie möglich, weil KI-Agenten Fehler inzwischen teils binnen Stunden wiederentdeckten. Die Ursache liegt laut OpenSSH außerhalb von sshd: Laut Forscherseite liefert die Funktion crypt() in musl bei einem Fehler die Zeichenkette * zurück. Das passiert laut Forscher bei Passwörtern über 256 Byte. Steht genau dieses Zeichen als Passwort-Hash eines Kontos in /etc/shadow, akzeptiert sshd unter den unten genannten Bedingungen ein beliebiges Passwort zwischen 257 und 1024 Zeichen.
Wer ist betroffen?
Laut Forscher, dessen Angaben BleepingComputer wiedergibt, müssen fünf Bedingungen zusammenkommen: ein Linux mit musl, sshd ohne PAM, aktivierte Passwortanmeldung, ein Konto mit * im Passwortfeld, etwa ein reines Schlüsselkonto, und ein weiteres Konto mit echtem Passwort-Hash. Ein frisches System ohne gesetzte Passwörter ist deshalb nicht betroffen. Konten mit gültigem Hash lassen sich nicht umgehen. Neben Alpine nennt der Forscher weitere musl-Systeme wie OpenWrt, Buildroot und Yocto, Dropbear ist laut seiner Seite nicht betroffen. In den offiziellen Alpine-Images für AWS und Azure ist laut Forscher das Standardkonto alpine betroffen, das passwortlose doas-Rechte hat, also faktisch Root.
Wie kritisch ist das?
OpenSSH stuft den Fehler als kritisch ein, einen CVSS-Wert nennen die Quellen nicht. Der Angriffspfad ist eine Anmeldung aus dem Netz ohne gültiges Passwort, bei Konten mit Administratorrechten also die volle Übernahme des Systems. Von Angriffen berichtet bisher keine der Quellen. Nach bisherigem Wissen ist der Fehler laut Forscher lange niemandem aufgefallen. Docker-Container auf Alpine-Basis sind nach Einschätzung von S-EDV nur relevant, wenn darin ein sshd läuft.
Was sollten Admins jetzt tun?
- Inventar: alle Systeme mit musl und erreichbarem sshd erfassen, also Alpine-Server und -VMs sowie OpenWrt-, Buildroot- und Yocto-Geräte, auf denen OpenSSH statt Dropbear läuft.
- Sofortmaßnahme nach Empfehlung von Alpine und OpenSSH:
PasswordAuthentication noin der sshd-Konfiguration setzen und sshd neu starten. Vorher sicherstellen, dass die Anmeldung per Schlüssel funktioniert. - Update: auf Alpine
apk upgrade openssh. In Alpine edge steht 10.6_p2-r0 bereit, laut Alpine wird der Fix bis Alpine 3.16 zurückportiert. - Prüfen: in
/etc/shadownach Konten mit*im Passwortfeld suchen und in/var/log/messagesnach „Accepted password“ für diese Konten. Ein solcher Treffer deutet laut Forscher auf eine Ausnutzung hin. - Instanzen aus den offiziellen Alpine-Images für AWS und Azure mit dem Konto
alpinegesondert prüfen.
Einordnung für Unternehmen
Die Lücke trifft eine kleine, aber oft vergessene Gruppe: schlanke Alpine-VMs, Bastion-Hosts und Netzwerkgeräte, die selten im Patchmanagement auftauchen. Wer die Passwortanmeldung in sshd mit PasswordAuthentication no abgeschaltet hat, war schon vorher geschützt. Der Fall zeigt erneut, dass abgeschaltete Passwortanmeldung eine sinnvolle Grundeinstellung für jeden erreichbaren Server ist.
Passende Anleitungen auf S-EDV
- VPS absichern und härten: UFW, SSH-Schlüssel und Fail2Ban unter Ubuntu und Debian
- Firewall für den Docker-Host: nftables, SSH auf eigenem Port und Teergrube
- OpenSSH 10.6: Sicherheitskorrekturen und neue Signaturen
