OpenSSH 10.6p2: SSHole-Lücke auf musl-Systemen

OpenSSH 10.6p2 ist ein Notfall-Release, das die OpenSSH-Entwickler am 5. November 2026 veröffentlicht haben. Es schließt eine Lücke, die unter dem Spitznamen „SSHole“ bekannt wurde und als CVE-2026-123158 geführt wird: Auf Linux-Systemen mit der C-Bibliothek musl und ohne PAM konnten Angreifer sich an bestimmten Konten anmelden, ohne das Passwort zu kennen. Laut den OpenSSH-Release-Notes handelt es sich um einen „critical security workaround“; die Ursache liege zwar außerhalb von sshd, sei aber über sshd ausnutzbar. Betroffen ist vor allem Alpine Linux – und damit eine Distribution, die in Containern, Cloud-Images und Embedded-Geräten weit verbreitet ist.

Die gute Nachricht vorweg: Der klassische Server mit Debian, Ubuntu oder Fedora ist nicht betroffen. Die schlechte: Wer Alpine-Hosts mit erreichbarem SSH-Port betreibt, sollte nicht bis Montag warten. Erste Angriffsversuche wurden nach Medienberichten bereits wenige Stunden nach der Veröffentlichung beobachtet.

OpenSSH 10.6p2: Was die Lücke ausmacht

Gefunden hat den Fehler Özgün Kültekin vom Sicherheitsunternehmen Wakefield. Das Problem entsteht aus dem Zusammenspiel zweier für sich genommen nachvollziehbarer Designentscheidungen. OpenSSH prüft Passwörter ohne PAM, indem es den eingegebenen Wert mit der Bibliotheksfunktion crypt() hasht und mit dem gespeicherten Eintrag vergleicht. Für Konten ohne nutzbaren Hash – etwa reine Key-Only-Accounts, deren Passwortfeld in /etc/shadow nur ein * enthält – leiht sich sshd seit Jahren das Salt eines anderen Kontos. Das war eine Schutzmaßnahme gegen Timing-Angriffe, mit denen sich sonst herausfinden ließe, welche Benutzernamen existieren.

musl wiederum liefert bei bestimmten Fehlerfällen von crypt(), etwa bei überlangen Eingaben, als Fehlerkennung genau den String * zurück. Wie das Alpine-Security-Advisory erklärt, stimmt dieser Fehlerwert dann mit dem gespeicherten Feld des passwortlosen Kontos überein – und sshd wertet den Vergleich als Erfolg. Ein Konto, das eigentlich nie ein Passwort akzeptieren sollte, lässt sich so per Passwort-Login öffnen.

Die NVD-Beschreibung fasst es nüchtern zusammen: sshd in OpenSSH vor 10.6p2 auf Linux mit musl und ohne PAM fehlt ein Workaround für einen Authentifizierungs-Bypass. Die CNA MITRE bewertet die Lücke mit CVSS 8.1 (High). Eine eigene NVD-Bewertung lag zum Zeitpunkt dieses Artikels noch nicht vor.

Wer betroffen ist – und wer nicht

Laut Alpine müssen mehrere Bedingungen gleichzeitig erfüllt sein:

• Es läuft das Alpine-Paket openssh-server, das ohne PAM gebaut ist, oder openssh-server-pam mit UsePAM no.
• PasswordAuthentication steht auf yes – das ist der OpenSSH-Standard, sofern niemand ihn geändert hat.
• Es gibt ein Konto mit * im Passwortfeld. Dazu zählen Key-Only-Benutzer, über musl-nscd eingebundene Verzeichnisdienst-Konten und seit etwa Alpine 3.16 auch root.
• Mindestens ein anderes lokales Konto besitzt einen klassischen SHA-256- oder SHA-512-Passworthash.

Root selbst ist durch die Standardeinstellung PermitRootLogin prohibit-password geschützt. Das hilft aber wenig, wenn ein anderes erreichbares Konto ohne Passwort Root-Rechte erlangen kann. Genau das ist bei den offiziellen Alpine-Cloud-Images (tiny-cloud) der Fall: Die Versionen 3.18.11 bis 3.24.3 liefern einen Benutzer alpine mit *-Passwortfeld und passwortlosem doas. Beim ersten Boot sind diese Images laut Alpine sicher – angreifbar werden sie, sobald auf der Maschine irgendein Passworthash entsteht, etwa weil ein Admin ein Konsolen-Passwort setzt.

Nicht betroffen sind nach Angaben von Alpine und dem Entdecker: glibc-basierte Distributionen wie Debian, Ubuntu oder Fedora, Setups mit PAM, Systeme mit PasswordAuthentication no, über cloud-init konfigurierte Cloud-Images (die Passwort-Login abschalten) sowie Container, in denen kein sshd läuft. Auch gesperrte Konten mit ! im Passwortfeld sind nicht erreichbar. Neben Alpine nennt der Entdecker weitere musl-basierte Umgebungen wie OpenWrt, Buildroot und Yocto als prüfenswert.

Bereits ausgenutzt

Brisant ist die Geschwindigkeit. Wie Help Net Security unter Berufung auf den Threat-Intelligence-Anbieter Previdian berichtet, kam der erste beobachtete Angriffsversuch weniger als neun Stunden nach Veröffentlichung der CVE; auf einem Honeypot mit echtem Alpine Linux sei Root-Zugriff gelungen. Previdian zählte zum Berichtszeitpunkt acht Versuche von einer einzelnen Adresse. In den KEV-Katalog der US-Behörde CISA war die Lücke laut dem Bericht noch nicht aufgenommen. Auf GitHub kursieren zudem angebliche Proof-of-Concept-Exploits, vor denen Previdian ausdrücklich warnt: Sie seien unverifiziert und könnten Malware enthalten. Wir verlinken sie bewusst nicht.

Bemerkenswert ist auch der Kontext im Release-Text selbst. Das OpenSSH-Team schreibt, es erhalte derzeit eine große Zahl von Sicherheitsmeldungen, viele davon von KI-Modellen oder mit KI-Unterstützung gefunden. Weil solche Funde häufig kurz darauf unabhängig von anderen entdeckt würden, wolle man vorerst häufiger Releases veröffentlichen, statt Fixes zu sammeln. Der Entdecker selbst gab an, mit „Agent-Schwärmen“ rund 17.600 ungewöhnliche Login-Versuche gegen verschiedene Builds gefahren zu haben. Das Muster kennen wir schon aus dem Fall Patch Gap und GLM 5.3: Die Zeit zwischen Patch und Angriff schrumpft.

Was Admins jetzt tun sollten

1. Aktualisieren und sshd neu starten. Alpine hat gepatchte Pakete für alle Branches von 3.16 bis edge bereitgestellt; die Point-Releases 3.21.10, 3.22.8, 3.23.8 und 3.24.4 enthalten den Fix. Auf edge ist es openssh 10.6_p2-r0, auf älteren Branches eine gepatchte Paketrevision (etwa 10.3_p1-r2 für 3.24). Wichtig: Ein Paket-Update ersetzt den laufenden Daemon nicht. Erst nach einem Neustart von sshd ist die Lücke geschlossen.

2. Falls kein Update möglich ist: Passwort-Login abschalten. PasswordAuthentication no in der sshd-Konfiguration schließt die Lücke ebenfalls. Vorher sicherstellen, dass der Key-Login funktioniert, und die aktuelle Sitzung offen lassen, bis ein neuer Login getestet ist. OpenSSH-Entwickler Damien Miller riet Betreibern betroffener Systeme öffentlich, genau das sofort zu tun.

3. Auf Spuren prüfen. Alpine empfiehlt, in /var/log/messages nach sshd-Einträgen „Accepted password for“ zu suchen, die Konten ohne Passwort betreffen – etwa alpine, root oder Key-Only-Benutzer. Zusätzlich sollten doas-Nutzung, neu angelegte Benutzer und authorized_keys-Dateien geprüft werden. Lässt sich ein unberechtigter Login nicht ausschließen, sollte die Maschine als kompromittiert gelten.

4. Container-Images und Appliances nicht vergessen. Wer eigene Images auf Alpine-Basis baut, in denen sshd läuft, muss diese neu bauen und ausrollen. Bei Routern und Embedded-Geräten mit OpenWrt oder Yocto lohnt ein Blick in die Hinweise der jeweiligen Hersteller.

Was sonst in OpenSSH 10.6p2 steckt

Neben dem Sicherheitsfix enthält das Release einige Bugfixes aus dem stabilen 10.6-Zweig. So ist das hybride Post-Quantum-Signaturverfahren ssh-mldsa44-ed25519 nun als CA-Signaturalgorithmus zugelassen, und ein kurzer CPU-Spin bei aktiver ChannelTimeout-Option wurde behoben. Hinzu kommen Portabilitätskorrekturen, etwa für die Sandbox unter seccomp. Für die meisten glibc-Systeme ist 10.6p2 damit ein reguläres Wartungsupdate, das über die normalen Distributionskanäle kommt.

Einordnung

SSHole ist kein Fehler, der „das Internet“ gefährdet. Die Kombination aus musl, fehlendem PAM, aktivem Passwort-Login und einem Mix aus Konten mit und ohne Passwort ist spezifisch. Gerade diese Kombination ist aber in Alpine-basierten Umgebungen der Normalfall, und Alpine steckt in vielen Images, die Teams einmal gebaut und dann vergessen haben. Wer SSH grundsätzlich nur per Schlüssel erlaubt, war schon vorher auf der sicheren Seite – das ist die eigentliche Lehre. Ähnlich wie bei der Symfony-Serializer-Lücke CVE-2026-118515 von dieser Woche gilt: Patchen ist Pflicht, aber sichere Standardkonfigurationen begrenzen den Schaden, bevor ein Patch existiert. Und wie der Fall der manipulierten Claude-Code-Extension mit SSH-Hintertür gezeigt hat, bleibt SSH ein bevorzugtes Einfallstor.

Hinweis: Dieser Artikel beschreibt Ursache, Betroffenheit und Abhilfe auf Basis der Herstellerangaben. Angriffsdetails und Exploit-Code geben wir bewusst nicht wieder.