Eine Grafik mit rotem Hintergrund, die eine digitale IT-Struktur in einem abstrakten Design darstellt. Geeignet für technische Themen.
Die OpenSSH Sicherheitslücke CVE-2026-123158, genannt „SSHole“, erlaubt Angreifern die Anmeldung an Konten, die eigentlich gar kein Passwort annehmen dürfen. Dafür genügt ein beliebiges Passwort mit 257 bis 1.024 Zeichen. Betroffen sind Linux-Systeme, die OpenSSH auf der C-Bibliothek musl ohne PAM betreiben, allen voran Alpine Linux. Weniger als neun Stunden nach der Veröffentlichung registrierte das Threat-Intelligence-Unternehmen Previdian die ersten Angriffe.
Das Wichtigste in Kürze
- CVE-2026-123158 (CVSS 8.1) betrifft den SSH-Server von OpenSSH vor Version 10.6p2 auf Linux-Systemen mit musl libc, die Passwörter ohne PAM prüfen.
- Konten mit gesperrtem Passwort, etwa root, reine Schlüssel-Konten oder der Standardbenutzer auf den Cloud-Images von Alpine, akzeptieren jedes Passwort mit 257 bis 1.024 Zeichen.
- Debian, Ubuntu, Red Hat und andere Distributionen mit glibc sind nicht betroffen, ebenso Systeme mit PAM und der SSH-Server Dropbear.
- Die Lücke wird bereits ausgenutzt: Bis zum 8. November 2026 zählte Previdian 20 Angriffsversuche von 13 IP-Adressen.
- Abhilfe bringt OpenSSH 10.6p2 vom 5. November 2026; bis zum Update hilft es, die Anmeldung per Passwort abzuschalten.
So funktioniert die OpenSSH Sicherheitslücke
Unter Linux steht im Passwortfeld eines Kontos ein Hash des Passworts. Konten, die sich gar nicht per Passwort anmelden sollen, tragen dort stattdessen einen Stern (*). Das ist üblich für root auf Alpine, für Dienst- und Deploy-Konten, die nur mit SSH-Schlüsseln arbeiten, und für Benutzer, die über LDAP verwaltet werden.
Beim Anmelden berechnet der SSH-Server aus dem eingegebenen Passwort einen Hash und vergleicht ihn mit dem gespeicherten Wert. Laut The Hacker News schlägt diese Berechnung unter musl bei Passwörtern zwischen 257 und 1.024 Zeichen fehl und liefert dann ebenfalls einen Stern zurück. Der Vergleich mit dem gespeicherten Stern geht auf, und der SSH-Server lässt den Angreifer herein. Der Fehler stammt aus einem Patch von 2016, der damals eine andere Lücke zur Ermittlung von Benutzernamen schließen sollte.
Welche Systeme von SSHole betroffen sind
Für einen erfolgreichen Angriff müssen laut der Projektseite sshhole.com mehrere Bedingungen zusammenkommen:
- Der SSH-Server läuft auf musl libc, etwa unter Alpine Linux, OpenWrt, Buildroot oder Yocto.
- Er prüft Passwörter ohne PAM. Das ist beim OpenSSH-Paket von Alpine die Standardeinstellung.
- Die Anmeldung per Passwort ist aktiv, wie es ab Werk der Fall ist.
- Es gibt ein Konto mit Stern im Passwortfeld und zusätzlich mindestens ein Konto mit echtem Passwort.
Besonders heikel sind laut sshhole.com die offiziellen Alpine-Images für AWS und Azure. Dort ist der Standardbenutzer alpine betroffen, und er darf per doas ohne Passwort Befehle als root ausführen. Ein Angreifer hat damit sofort volle Kontrolle über die Maschine. Laut borncity sind zudem viele Docker-Images betroffen, weil sie auf Alpine aufbauen.
Weniger sichtbar, aber praktisch relevant sind Geräte mit eingebettetem Linux. Router, Access Points, NAS, Kameras und Steuerungen in der Haustechnik basieren häufig auf OpenWrt, Buildroot oder Yocto. Ob ein bestimmtes Gerät betroffen ist, hängt davon ab, welche SSH-Software der Hersteller einsetzt und wie er sie konfiguriert hat. Diese Information liefert nur der Hersteller.
Debian, Ubuntu und Red Hat sind nicht betroffen
Nicht betroffen sind Debian, Ubuntu, Red Hat, SUSE und andere Distributionen mit glibc, alle Systeme mit PAM, der alternative SSH-Server Dropbear sowie Systeme außerhalb von Linux. Typische Server-Installationen im Mittelstand fallen damit heraus. Für diese Server bleibt aber die Linux-Kernel-Lücke aus der Vorwoche wichtig; mehr dazu in unserem Beitrag Linux-Kernel-Lücke CVE-2026-98432 im TCP-Stack.
Zahlen, Daten, Fakten zu SSHole
| Kennzahl | Wert |
|---|---|
| Einstufung von CVE-2026-123158 | CVSS 8.1 (hoch) |
| Länge des beliebigen Passworts | 257 bis 1.024 Zeichen |
| Zeit bis zum ersten beobachteten Angriff | unter 9 Stunden |
| Angriffsversuche bis 8. November 2026 | 20 von 13 IP-Adressen aus neun Ländern |
| Fehler im Code seit | 2016 |
Previdian bestätigt laut The Hacker News einen erfolgreichen root-Zugriff auf einem Honeypot mit Alpine Linux. Die Angreifer führten danach erste Erkundungsbefehle wie id, uname und hostname aus. Das Muster ist typisch für automatisierte Scans, die erreichbare Systeme zunächst nur katalogisieren.
Empfehlungen für IT-Admins
1
Betroffene Systeme finden
Erfassen Sie Server, VMs und Container auf Basis von Alpine, die einen SSH-Dienst anbieten. Prüfen Sie auch Cloud-Instanzen aus den offiziellen Alpine-Images.
2
OpenSSH aktualisieren
Spielen Sie OpenSSH 10.6p2 oder das korrigierte Paket der Distribution ein und starten Sie sshd neu. Unter Alpine genügt apk upgrade openssh.
3
Passwort-Anmeldung abschalten
Wo das Update nicht sofort möglich ist, setzen Sie PasswordAuthentication no und starten sshd neu. SSH sollte ohnehin nur mit Schlüsseln arbeiten und nicht direkt aus dem Internet erreichbar sein.
4
Konfiguration prüfen
Der Befehl sshd -T zeigt die wirksamen Einstellungen. Ist dort usepam no und passwordauthentication yes gesetzt, ist das System bei veraltetem OpenSSH angreifbar.
5
Spuren suchen
Laut Alpine sollten Sie in /var/log/messages nach Zeilen „Accepted password for“ suchen, die Konten ohne Passwort betreffen, etwa alpine, root oder reine Schlüssel-Konten. Prüfen Sie zusätzlich die doas-Nutzung, neu angelegte Benutzer und Dateien sowie hinterlegte SSH-Schlüssel.
6
Geräte mit eingebettetem Linux einbeziehen
Klären Sie bei Routern, Access Points, NAS und anderen Appliances mit SSH-Zugang, ob der Hersteller einen Hinweis zu CVE-2026-123158 veröffentlicht hat. Schalten Sie SSH dort ab, wo es nicht gebraucht wird, und beschränken Sie den Zugriff auf das Verwaltungsnetz.
Wichtig für IT-Admins
Lässt sich eine unbefugte Anmeldung nicht sicher ausschließen, empfiehlt Alpine, die Maschine als übernommen zu behandeln. In der Praxis heißt das: System neu aufsetzen, Zugangsdaten und Schlüssel tauschen, die auf der Maschine lagen, und angebundene Systeme prüfen. Ein bloßes Update schließt die Tür, entfernt aber keinen Angreifer, der schon drin ist.
Bedeutung für Geschäftsführung und Entscheider
SSHole trifft vor allem Systeme, die selten jemand im Blick hat. Klassische Windows- und Linux-Server im Unternehmen sind in aller Regel nicht betroffen. Gefährdet sind Container, Cloud-Instanzen aus Standard-Images und Geräte mit eingebettetem Linux, die einmal eingerichtet und danach kaum noch angefasst werden.
Das Risiko ist konkret, weil Angreifer die Lücke bereits automatisiert ausnutzen. Ein übernommenes System dient als Sprungbrett ins Netz: Laut Safe Security können Angreifer an Zugangsdaten für Deployments, Anwendungsgeheimnisse und angebundene Infrastruktur gelangen.
Der Aufwand für die Abwehr ist überschaubar. Das Update und das Abschalten der Passwort-Anmeldung sind Arbeiten von Minuten je System. Aufwendiger ist die Frage, welche Systeme überhaupt betroffen sind. Eine aktuelle Inventarisierung aller Server, Container und Netzwerkgeräte mit SSH-Zugang zahlt sich hier unmittelbar aus.
FAQ zu SSHole
Nein. Debian, Ubuntu, Red Hat und andere Distributionen mit glibc sind laut sshhole.com und The Hacker News nicht betroffen. Gleiches gilt für alle Systeme, die Passwörter über PAM prüfen.
musl ist eine schlanke C-Standardbibliothek für Linux. Sie steckt vor allem in Alpine Linux, in vielen Docker-Images und in Firmware für Router und andere Geräte mit eingebettetem Linux.
Ja. Previdian beobachtete den ersten Angriff weniger als neun Stunden nach Veröffentlichung der CVE und bis zum 8. November 2026 insgesamt 20 Versuche von 13 IP-Adressen. Auf einem Honeypot mit Alpine erlangten die Angreifer root-Rechte.
Als Sofortmaßnahme ja. Mit PasswordAuthentication no greift SSHole nicht mehr. Das Update auf OpenSSH 10.6p2 sollte trotzdem folgen, damit die Einstellung nicht später versehentlich zurückgesetzt wird.
Suchen Sie in /var/log/messages nach "Accepted password for" bei Konten, die kein Passwort haben. Ergänzend prüfen Sie doas-Aufrufe, neue Benutzer und hinterlegte SSH-Schlüssel.
Fazit
Die OpenSSH Sicherheitslücke SSHole betrifft eine überschaubare Gruppe von Systemen: Alpine-Server, Container und Geräte mit eingebettetem Linux. Wo diese Bedingungen zutreffen, öffnet ein langes Passwort die Tür zu Konten, die nie ein Passwort hatten, im ungünstigsten Fall direkt mit root-Rechten. Da Angreifer die Lücke bereits ausnutzen, gehört das Update auf OpenSSH 10.6p2 in diese Woche. Wer zusätzlich die Passwort-Anmeldung per SSH grundsätzlich abschaltet, ist auch gegen die nächste Lücke dieser Art besser aufgestellt.
Fanden Sie den Blogbeitrag hilfreich und interessant?
Vielen Dank für Ihre Rückmeldung!