Alpine Linux hat am 5. November eine Sicherheitsmitteilung zu einer OpenSSH-Authentifizierungsumgehung veröffentlicht, mit der Angreifer sich an Konten anmelden können, die Passwort-Logins ausdrücklich ablehnen. Die als CVE-2026-123158 geführte und *sshole getaufte Lücke wird mit 8.1 (hoch) bewertet; der Fehler dahinter reicht bis 2016 zurück. Das korrigierte OpenSSH 10.6p2 erschien am selben Tag, und Alpine hat den Fix bis zurück zu 3.16 in alle Zweige eingespielt — auch in nicht mehr unterstützte Releases.

Der Mechanismus ist ein Streit zwischen drei Komponenten, die jede für sich vernünftig handelten. In musl libc — der C-Bibliothek, die Alpine statt glibc nutzt — verweigert crypt() Passwörter über 256 Byte und gibt die Zeichenkette * zurück. Linux verwendet * in /etc/shadow als Kennzeichen dafür, dass ein Konto keinen nutzbaren Passwort-Hash hat. 2016 führte OpenSSH ein Verhalten ein, um nicht zu verraten, welche Benutzernamen existieren; auf musl-Systemen ohne PAM kann dabei mit Einstellungen eines anderen Kontos gehasht werden, selbst wenn das Zielkonto keinen gültigen Hash besitzt. Schickt man ein Passwort zwischen 257 und 1.024 Byte an ein Konto, dessen Shadow-Eintrag lautet, stimmt der Vergleich: gleich *. Die Anmeldung gelingt.

Die Voraussetzungen sind spezifisch, aber nicht exotisch. Der Server muss musl ohne PAM nutzen, wie es Alpines openssh-server standardmäßig tut; Passwort-Authentifizierung muss aktiv sein; das Zielkonto muss * statt ! in shadow haben; und mindestens ein weiteres Konto auf dem System muss ein echtes Passwort besitzen. Wo all das zutrifft — reine Key-only-Nutzer, root auf Alpine seit 3.16 und der Standardnutzer alpine auf Alpines AWS- und Azure-Images, der doas ohne Passwort ausführen darf — genügt ein einziger Anmeldeversuch, und auf diesen Cloud-Images bedeutet das root. Gefunden wurde die Lücke von Özgün Kültekin von Wakefield, der laut veröffentlichter Recherche sshd in jeder Kombination aus glibc, musl, PAM und ohne PAM baute und auf jede rund 17.600 ungewöhnliche Anmeldeversuche schickte. Alle Builds verhielten sich — bis auf musl ohne PAM, das Ja sagte.

Debian, Ubuntu und Fedora sind auf diesem Pfad nicht betroffen, ebenso wenig PAM-basierte Server, Hosts mit PasswordAuthentication no, Konten mit !, Container ohne sshd oder Dropbear. Diese Liste ist wichtig: Ein Großteil der Frage, ob ein System betroffen ist, läuft darauf hinaus, ob im Container-Image einer Alpine-Basis ein sshd läuft, das die CI vor Monaten gebaut hat.

Der Fix weist gespeicherte Hashes zurück, die zu kurz für einen echten Hash sind, sodass ein fehlgeschlagener Hash nicht mehr als Treffer durchgeht. Das Paket zu patchen ist nicht dasselbe wie den laufenden Prozess zu patchen — sshd muss neu gestartet werden — und Images neu zu bauen ist wichtiger als ein Host-Upgrade: Nur ein korrigiertes Basis-Image verhindert, dass der Fehler mit dem nächsten Deployment zurückkommt. Wer noch nicht aktualisieren kann, schließt die Lücke mit PasswordAuthentication no und reiner Schlüssel-Anmeldung. Zur Kontrolle in den Logs nach „Accepted password" für Konten suchen, die kein Passwort haben sollten; wer fündig wird, sollte die Maschine als kompromittiert behandeln.

Quellen