OpenSSH-Lücke erlaubt Anmeldeumgehung auf Alpine Linux
OpenSSH 10.6p2 schließt eine Anmeldeumgehung im SSH-Server auf musl-basierten Systemen wie Alpine Linux. Betroffen sind Server ohne PAM mit erlaubten Passwortanmeldungen und einer bestimmten Kontenkonstellation. Nach dem Update gehört ein ausdrücklicher Neustart von sshd dazu, die Versionsnummer allein zeigt den Schutz nicht zuverlässig an.
Das Wichtigste in Kürze
- OpenSSH 10.6p2 schließt eine Anmeldeumgehung auf musl-Systemen. Betroffen sind ältere Versionen mit UsePAM=no und PasswordAuthentication=yes.
- Auf Alpine entscheidet die Kontenlage über die Betroffenheit. Nötig sind ein Zielkonto mit * im Passwortfeld und ein weiteres lokales Konto mit SHA-256- oder SHA-512-Passworthash.
- Zum Update gehört ein Neustart von sshd. Gepatchte Alpine-Pakete behalten ältere Versionsnummern, die Kennung allein zeigt die Verwundbarkeit nicht zuverlässig.
Verwandt: Oracle stopft 1.209 Lücken mit 112 kritischen Patches
Eine Lücke mit Vorbedingungen
Für Administratoren ist der SSH-Server die übliche Tür zu entfernten Linux-Maschinen. Seit dem 5. November ist klar, dass sich diese Tür auf bestimmten Systemen ohne gültiges Passwort öffnen lässt. OpenSSH 10.6p2 verhindert diese Anmeldeumgehung im SSH-Server. Betroffen sind OpenSSH-Versionen vor 10.6p2 auf Basis von musl, sofern der Server mit UsePAM=no und PasswordAuthentication=yes läuft.
musl ist eine kompakte C-Standardbibliothek, also jene Grundschicht, über die Programme unter Linux elementare Funktionen aufrufen. Alpine Linux baut auf musl auf. PAM steht für Pluggable Authentication Modules und regelt die Anmeldung über austauschbare Module. Ob eine Maschine verwundbar ist, entscheiden damit Konfiguration und Kontenlage.
Was ist PAM? PAM steht für Pluggable Authentication Modules, eine Schnittstelle, über die Linux-Dienste Anmeldungen an austauschbare Module übergeben. Ein SSH-Server muss die Passwortprüfung damit nicht selbst erledigen. Auf Alpine steckt OpenSSH mit PAM-Unterstützung im Paket openssh-server-pam und nutzt PAM mit der Einstellung UsePAM yes.
Konten mit Sternchen im Passwortfeld
Auf Alpine-Systemen greift die Lücke nur, wenn mehrere Bedingungen zusammenkommen. SSH läuft ohne PAM und erlaubt Passwortanmeldungen. Das Zielkonto trägt im Passwortfeld ein Sternchen * und hat damit kein nutzbares Passwort. Ein weiteres lokales Konto besitzt einen Passworthash nach dem Verfahren SHA-256 oder SHA-512. Unter diesen Voraussetzungen sind die geprüften Alpine-Versionen 3.16 bis 3.24 betroffen, ebenso der Entwicklungszweig edge.
In eigenen Tests von Check Point setzte der Angriff ein weiteres aktives Konto mit echtem Passwort voraus. Ein gespeicherter Passworthash allein genügte dort nicht. Ausgenommen sind Systeme, die das Paket openssh-server-pam nutzen und UsePAM yes gesetzt haben.
Vom Cloud-Image bis Root
Eine vollständige Angriffskette betrifft Images mit tiny-cloud, dem Werkzeug, das Alpine-Instanzen in der Cloud beim Start einrichtet. Ist auf einem betroffenen Image ein SHA-512-Passworthash angelegt, gelingt die Anmeldung als Benutzer alpine. Von dort führt passwortloses doas zu Root-Rechten. doas ist eine kompakte Alternative zu sudo und erlaubt Benutzern, Befehle mit erweiterten Rechten auszuführen. Aus der Anmeldeumgehung wird so die volle Kontrolle über die Instanz.
Versionsnummer verrät den Patch nicht
Wer die Lage im eigenen Bestand prüft, stößt auf ein Inventarproblem. Gepatchte Alpine-Pakete behalten ältere OpenSSH-Versionsnummern. Für Alpine 3.24 trägt das korrigierte Paket beispielsweise die Kennung 10.3_p1-r2. Die Versionskennung allein lässt deshalb nicht zuverlässig erkennen, ob ein System verwundbar ist.
Eine Abfrage, die nur nach OpenSSH 10.6p2 sucht, greift auf Alpine damit zu kurz. Für eine belastbare Prüfung gehören Paketrevision, sshd-Einstellungen und die Passwortfelder der lokalen Konten zusammen.
Sofortmaßnahmen für Betreiber
Betroffene Betreiber sollen OpenSSH aktualisieren und sshd anschließend ausdrücklich neu starten. Wo ein Update nicht sofort möglich ist, sollen sie PasswordAuthentication no setzen und sshd ebenfalls neu starten. Damit sind Passwortanmeldungen am SSH-Server abgeschaltet.
Dazu kommt der Blick zurück. Betreiber sollen im Systemprotokoll /var/log/messages nach Passwortanmeldungen an passwortlosen Konten suchen. Lässt sich eine solche Anmeldung nicht ausschließen, ist die Maschine als kompromittiert zu behandeln.
Häufige Fragen
Jede Frage ist verschlossen. Ein Tippen entriegelt die Antwort.
Ist auch Dropbear betroffen?
Nein. Die Anmeldeumgehung betrifft OpenSSH. Dropbear, ein kompakter alternativer SSH-Server, ist ebenso wenig betroffen wie andere Software außerhalb von OpenSSH, die passwortbasierte Anmeldungen nutzt.
Sind Container gefährdet?
Container ohne laufenden sshd sind ausgenommen. Für die Bewertung eines Containers zählt damit zuerst, ob darin ein SSH-Server aktiv ist.
Gibt es eine CVE-Kennung?
Nach Angaben von GitHub ist die Lücke als CVE-2026-123158 erfasst. Der Advisory-Eintrag stammt vom 5. November und ist als ungeprüft markiert. Er beschreibt die Anmeldeumgehung in OpenSSH vor 10.6p2 unter Linux mit musl ohne PAM.
Lesetipps der Redaktion
LesetippLinux-Kernel-Lücke: Ubuntu liefert noch keinen PatchLesetippLiteLLM-Update stiehlt Zugangsdaten aus KI-UmgebungenLesetippOracle stopft 1.209 Lücken mit 112 kritischen Patches
Bildquelle: KI-generiert (November 2026)
Mehr aus dem MBF Media Netzwerk
cloudmagazinKI-Agenten als Kunden: Was der Kundenservice jetzt braucht
MyBusinessFutureLogistik-Studie: Wo die Verkehrswende stecken bleibt
Digital ChiefsEdge AI im Einsatz
