SSHHole: OpenSSH-Lücke CVE-2026-123158 lässt Angreifer ohne Passwort auf Alpine-Server
Ein einziges, absurd langes Passwort genügt, und ein Server öffnet seine Tür für einen Fremden. Was wie ein schlechter Witz klingt, ist seit dem 5. November 2026 eine dokumentierte Sicherheitslücke. Sie trägt den Spitznamen SSHHole und die Kennung CVE-2026-123158. Betroffen sind Server, die OpenSSH auf Linux mit der C-Bibliothek musl betreiben, ohne dass Passwörter über PAM geprüft werden. In der Praxis heißt das vor allem: Alpine Linux. Die Lücke ist mit CVSS 8.1 als hoch eingestuft, ein Notfall-Update liegt bereits vor, und laut Sicherheitsforschern gab es schon wenige Stunden nach der Veröffentlichung erste Angriffsversuche.
Was ist SSHHole?
SSHHole ist ein Fehler in der Passwortprüfung des SSH-Servers sshd in OpenSSH-Versionen vor 10.6p2. Entdeckt hat ihn der Sicherheitsforscher Özgün Kültekin vom Unternehmen Wakefield. Der Kern des Problems liegt in der Zusammenarbeit zwischen OpenSSH und der musl-Bibliothek. Auf betroffenen Systemen prüft sshd Passwörter ohne PAM über die Funktion crypt() aus musl. Dabei kann ein Passwort mit 256 bis 1024 Zeichen als gültig akzeptiert werden, selbst wenn das Konto eigentlich gar kein Passwort besitzt.
Das betrifft Konten, deren Passwortfeld in der Datei /etc/shadow nur ein Sternchen enthält. Ein Sternchen bedeutet: Für dieses Konto ist kein reguläres Passwort hinterlegt, eine Anmeldung per Passwort ist nicht vorgesehen. Genau diese Konten nimmt SSHHole ins Visier. Laut dem Sicherheitshinweis von Alpine Linux gehören dazu unter anderem das Konto root, reine Schlüssel-Nutzer für den Einsatz von Software, LDAP-Nutzer und der Standardnutzer der offiziellen Alpine-Images für AWS und Azure. Für einen Angreifer reicht eine einzige SSH-Verbindung, und es sind keine Wiederholungsversuche nötig.
Wichtig für die Einordnung: Nicht jeder Linux-Server ist betroffen. Systeme mit der glibc-Bibliothek, also die verbreiteten Distributionen Debian, Ubuntu und Fedora, sind von diesem konkreten Fehler nicht betroffen. Auch Systeme, die Passwörter über PAM prüfen, und Systeme außerhalb von Linux sind laut dem OpenSSH-Betreuer Damien Miller nicht betroffen. Die Lücke braucht eine enge Kombination aus Betriebssystem, Bibliothek, SSH-Konfiguration und Konten, und genau diese Kombination ist bei Alpine Linux die Standardkonfiguration des Pakets openssh-server.
Welche Systeme sind betroffen?
Vier Bedingungen müssen gleichzeitig erfüllt sein, damit ein Server angreifbar ist. Erstens läuft eine OpenSSH-Version vor 10.6p2. Zweitens nutzt das System die musl-Bibliothek statt glibc. Drittens wird die Passwortprüfung nicht über PAM abgewickelt. Viertens ist die Passwortanmeldung für das betroffene Konto erlaubt, was in OpenSSH die Standardeinstellung ist. Zusätzlich muss auf dem System mindestens ein weiteres lokales Konto mit einem echten Passwort-Hash im SHA-256- oder SHA-512-Format existieren. Diese Zusatzbedingung hängt mit der Art zusammen, wie die fehlerhafte Prüfung abläuft.
Alpine Linux ist das bekannteste betroffene System, weil die Distribution wegen ihres geringen Ressourcenverbrauchs häufig auf Servern, in Cloud-Umgebungen und in Containern eingesetzt wird. Die Sicherheitsfirma SOCRadar nennt als besonders riskante Variante die offiziellen Alpine-Cloud-Images, die mit dem Werkzeug tiny-cloud gebaut werden. Dort trägt der Standardnutzer alpine ein Sternchen als Passwort und kann Befehle ohne Passwort als root ausführen, über das Werkzeug doas. Wer sich auf einem solchen System als alpine anmeldet, hat damit praktisch die volle Kontrolle über den Server. Die betroffenen Image-Versionen liegen nach Angaben von SOCRadar zwischen 3.18.11 und 3.24.3.
Erste Angriffe schon wenige Stunden nach der Veröffentlichung
Die Lücke wurde am 5. November 2026 veröffentlicht, und OpenSSH lieferte am selben Tag die korrigierte Version 10.6p2 aus. Alpine Linux stellte ebenfalls noch am selben Tag gepatchte Pakete für alle Zweige von Version 3.16 bis edge bereit. Doch die Angreifer ließen nicht lange auf sich warten. Das Sicherheitsunternehmen Previdian meldete, dass seine Sensoren den ersten Angriffsversuch weniger als neun Stunden nach der Veröffentlichung registrierten. Insgesamt zählte das Unternehmen acht Versuche, alle von einer einzigen Adresse in Japan aus.
Der Gründer von Previdian, Ryan Dewhurst, bestätigte gegenüber dem Fachportal Help Net Security, dass mindestens einer dieser Versuche auf einem Testsystem mit echtem Alpine Linux und OpenSSH bis zum Root-Zugriff gelang. Die beobachtete Quelladresse 89.116.89.18 nutzte überlange Passwörter, um die Anmeldung zu umgehen, und führte anschließend einfache Aufklärungsbefehle wie id, uname und hostname aus. Previdian hat die Lücke inzwischen auf die eigene Liste bekannter ausgenutzter Schwachstellen gesetzt. Die US-Behörde CISA hatte sie bis zum 6. November noch nicht in ihren Katalog bekannter ausgenutzter Schwachstellen aufgenommen.
Was Serverbetreiber jetzt tun sollten
Der wichtigste Schritt ist das Update. OpenSSH 10.6p2 schließt die Lücke. Die Korrektur sorgt dafür, dass sshd eine Übereinstimmung ablehnt, sobald das gespeicherte Passwortfeld kürzer als vier Zeichen ist. Auf Alpine Linux genügt der Befehl apk upgrade openssh, danach sollte der SSH-Dienst neu gestartet werden. Wer das Update nicht sofort einspielen kann, sollte die Passwortanmeldung deaktivieren und ausschließlich auf Schlüsselanmeldung setzen. Diese Maßnahme nimmt der Lücke ihre Grundlage, denn ohne Passwortanmeldung gibt es keine Passwortprüfung, die sich umgehen ließe.
Warum die Lücke so lange unentdeckt blieb
Besonders bemerkenswert ist das Alter des Fehlers. Laut dem Entdecker reicht die fehlerhafte Konstellation bis zur OpenSSH-Version 7.3p1 aus dem Jahr 2016 zurück. Die Lücke schlummerte damit rund zehn Jahre in der Software, bevor sie gefunden wurde. Das liegt auch daran, dass die betroffene Kombination selten ist. Die meisten Server nutzen glibc oder PAM, und dort tritt der Fehler gar nicht auf. Erst die Kombination aus musl, fehlendem PAM und einem Sternchen-Konto öffnet die Tür.
Frequently Asked Questions
Was ist SSHHole genau?
SSHHole ist der Spitzname für die Sicherheitslücke CVE-2026-123158 in OpenSSH. Auf Linux-Systemen mit der musl-Bibliothek und ohne PAM-Prüfung akzeptiert der SSH-Server Passwörter mit 256 bis 1024 Zeichen für Konten, die eigentlich gar kein Passwort haben. Die Lücke ist mit CVSS 8.1 als hoch eingestuft und wurde am 5. November 2026 veröffentlicht.
Bin ich betroffen, wenn ich Ubuntu oder Debian nutze?
Nein, von diesem konkreten Fehler sind Debian, Ubuntu und Fedora nicht betroffen. Diese Systeme nutzen die glibc-Bibliothek statt musl. Betroffen sind vor allem Alpine Linux und andere musl-Systeme, auf denen OpenSSH vor Version 10.6p2 ohne PAM läuft und die Passwortanmeldung aktiviert ist.
Wie schütze ich meinen Server vor SSHHole?
Spielen Sie das Update auf OpenSSH 10.6p2 ein, auf Alpine Linux mit dem Befehl apk upgrade openssh, und starten Sie den SSH-Dienst neu. Wenn das Update nicht sofort möglich ist, deaktivieren Sie die Passwortanmeldung und nutzen Sie ausschließlich Schlüssel. Prüfen Sie außerdem Ihre Konten und Protokolle auf ungewöhnliche Anmeldungen.



Post Comment