Eine Schwachstelle in OpenSSH mit dem Spitznamen „SSHole“ wird seit Anfang November 2026 für Angriffe genutzt. Unter bestimmten Bedingungen genügt ein beliebiges Passwort mit 257 bis 1.024 Byte Länge, um sich an einem Linux-System anzumelden, sofern der Angreifer den Namen eines passenden Kontos kennt – bis hin zu Administratorrechten. Die Lücke trägt die Kennung CVE-2026-123158 und ist mit OpenSSH 10.6p2 behoben. Betroffen sind allerdings nur Linux-Systeme mit der C-Bibliothek musl, vor allem Alpine Linux. Die verbreiteten Server-Distributionen Debian, Ubuntu und Red Hat sind es nicht.
Steckbrief der Lücke
| Merkmal | Angabe |
|---|---|
| Bezeichnung | SSHole |
| Kennung | CVE-2026-123158 |
| Art | Umgehung der Passwortprüfung im SSH-Dienst (sshd) |
| Bewertung | CVSS 8.1 (Hoch); BSI/CERT-Bund: Risiko „hoch“, Erlangen von Administratorrechten |
| Betroffen | OpenSSH vor 10.6p2 unter Linux mit musl libc und ohne PAM |
| Behoben | OpenSSH 10.6p2 vom 5. November 2026; unter Alpine zählt die Paketrevision: korrigiert in Alpine 3.21.10, 3.22.8, 3.23.8 und 3.24.4 sowie in Paketen für 3.16 bis 3.20 und edge |
| Nicht betroffen | Systeme mit glibc (Debian, Ubuntu, RHEL und abgeleitete), Systeme mit aktivem PAM (UsePAM yes), deaktivierte Passwortanmeldung |
| Ausnutzung | Ja, Angriffsversuche seit 5. November, erste erfolgreiche Angriffe ab 6. November gemeldet; seit 9. November im CISA-Katalog ausgenutzter Lücken |
So funktioniert die Lücke
Linux speichert Passwörter als Hash. Zur Prüfung berechnet der SSH-Dienst den Hash des eingegebenen Passworts mit der Funktion crypt() und vergleicht ihn mit dem gespeicherten Wert. Die schlanke C-Bibliothek musl, auf der Alpine Linux aufbaut, gibt bei sehr langen Eingaben über 256 Byte kein Ergebnis, sondern ein Sternchen „*“ als Fehlerzeichen zurück. Ein Sternchen steht aber auch im Passwortfeld von Konten, für die nie ein Passwort gesetzt wurde. Der Vergleich ergibt dann Gleichheit – und die Anmeldung gelingt.
Dafür müssen laut den Entwicklern von Alpine mehrere Bedingungen zusammenkommen: Die Passwortanmeldung ist eingeschaltet (Standard), der SSH-Dienst läuft ohne PAM, es gibt ein Konto mit „*“ im Passwortfeld und mindestens ein weiteres Konto mit einem regulären Passwort-Hash. Ein Konto mit „*“ ist auf Alpine üblich, etwa „root“ – das schützt allerdings die Voreinstellung „PermitRootLogin prohibit-password“. Gefährlich wird es, sobald ein weiteres Konto einen Passwort-Hash hat, etwa beim Standardkonto „alpine“ in tiny-cloud-Images, das über doas ohne Passwort Administratorrechte erhalten kann.
Angriffe seit Anfang November
Nach der Veröffentlichung eines Proof of Concept am 5. November begannen die ersten Angriffsversuche, erste erfolgreiche Angriffe wurden ab dem 6. November gemeldet. In den Sensoren des Sicherheitsunternehmens GreyNoise gelang der erste Einbruch am 7. November; insgesamt zählte es 16 erfolgreiche Angriffsketten von sechs IP-Adressen. In einem Fall erlangte der Angreifer Administratorrechte und installierte die Hintertür „TAC Agent“. Laut dem Sicherheitsunternehmen watchTowr wurde die Lücke zudem für Botnetze und das Schürfen von Kryptowährung ausgenutzt. Die US-Behörde CISA hat die Lücke am 9. November in ihren Katalog ausgenutzter Schwachstellen aufgenommen. Wie viele Systeme insgesamt betroffen sind, ist nicht bekannt.
Bin ich betroffen? So prüfen Sie Ihre Systeme
- Systeme mit musl finden. Alpine-Server, virtuelle Maschinen und Container-Images auf Alpine-Basis erfassen, in denen ein SSH-Dienst läuft. Auch Appliances und Firmware auf musl-Basis können betroffen sein; hier hilft die Rückfrage beim Hersteller.
- OpenSSH aktualisieren und den Dienst neu starten. Unter Alpine mit „apk upgrade -U -a“ aktualisieren und danach „rc-service sshd restart“ ausführen. Die Entwickler weisen ausdrücklich darauf hin: Das Paket-Update allein ersetzt den laufenden Dienst nicht.
- Passwortanmeldung abschalten, wo es geht. Wenn das Update nicht sofort möglich ist, in der sshd-Konfiguration „PasswordAuthentication no“ setzen. Vorher sicherstellen, dass die Anmeldung per Schlüssel funktioniert, und die laufende Sitzung offen halten. Die Einstellung auch in Match-Blöcken setzen, die Konfiguration mit „sshd -t“ testen und den Dienst mit „rc-service sshd restart“ neu starten; mit „sshd -T | grep -i passwordauthentication“ die wirksame Einstellung kontrollieren.
- Container-Images neu bauen. Images auf Alpine-Basis mit SSH-Dienst neu bauen und neu ausrollen. Laufende Instanzen aus älteren Cloud-Images aktualisieren oder ersetzen.
- Auf Einbrüche prüfen. Im Systemprotokoll nach „Accepted password for“ bei Konten suchen, die gar kein Passwort haben. Neue Benutzer, neue Dateien, geänderte authorized_keys und die Nutzung von doas prüfen. Lässt sich eine fremde Anmeldung nicht ausschließen, das System als kompromittiert behandeln und neu aufsetzen.
Einordnung: eine Nischenlücke mit ernstem Kern
Für die meisten mittelständischen Unternehmen ist SSHole kein Grund zur Unruhe – ihre Linux-Server laufen in aller Regel auf Debian, Ubuntu oder einer Red-Hat-Variante. Der Fall zeigt aber zwei Punkte, die überall gelten. Erstens: Die Anmeldung per Passwort an einem SSH-Dienst, der aus dem Internet erreichbar ist, ist ein vermeidbares Risiko; Schlüssel oder ein vorgeschalteter VPN-Zugang sind der bessere Weg. Zweitens: Container und kleine Hilfssysteme fallen bei Updates leicht durch, weil niemand sie als Server wahrnimmt.
In unserer Betreuung erfassen wir auch Container und Appliances im Bestand, betreiben SSH ausschließlich mit Schlüsseln und schotten Verwaltungszugänge über VPN ab. Sicherheitsupdates für Linux-Systeme spielen wir nach festen Fristen ein.
Häufige Fragen
Was ist SSHole?
Eine Lücke in OpenSSH mit der Kennung CVE-2026-123158. Auf Linux-Systemen mit der C-Bibliothek musl und ohne PAM lässt sich die Passwortprüfung des SSH-Dienstes mit einem beliebigen Passwort von 257 bis 1.024 Byte umgehen.
Sind Debian- oder Ubuntu-Server betroffen?
Nein. Debian, Ubuntu, Red Hat und davon abgeleitete Distributionen verwenden glibc und sind nicht betroffen. Betroffen ist vor allem Alpine Linux; das BSI führt zusätzlich Microsoft Azure Linux 3 als betroffen.
Welche OpenSSH-Version schließt die Lücke?
OpenSSH 10.6p2 vom 5. November 2026. Unter Alpine zählt die Paketrevision: Die stabilen Zweige erhalten die Korrektur als Rückportierung, etwa in Alpine 3.21.10, 3.22.8, 3.23.8 und 3.24.4.
Reicht es, das Paket zu aktualisieren?
Nein. Der laufende SSH-Dienst muss danach neu gestartet werden, unter Alpine mit „rc-service sshd restart“. Sonst läuft weiter die alte Version.
Was kann ich tun, wenn ich nicht sofort aktualisieren kann?
Die Passwortanmeldung mit „PasswordAuthentication no“ abschalten, den SSH-Dienst neu starten und nur noch Schlüssel zulassen. Vorher die Anmeldung per Schlüssel testen und die laufende Sitzung offen halten.
Wird die Lücke schon ausgenutzt?
Ja. Erste erfolgreiche Angriffe wurden ab dem 6. November 2026 gemeldet, seit dem 9. November steht die Lücke im CISA-Katalog ausgenutzter Schwachstellen.
Welche Version von OpenSSH ist die aktuelle?
Zum Stand dieses Beitrags ist OpenSSH 10.6p2 die aktuelle portable Version.
Verwandte Themen: Wer hier weiterdenkt, liest bei Linux-Server, Patch-Management und Switch-Absicherung weiter.
Im Text erwähnt
Quellen
- CVE-2026-123158 · NIST NVD
- OpenSSH Release Notes 10.6p2 · OpenSSH
- OpenSSH password authentication bypass · Alpine Linux
- WID-SEC-2026-4365: OpenSSH – Schwachstelle ermöglicht Erlangen von Administratorrechten · BSI / CERT-Bundamtlich
- Hackers exploit SSHole OpenSSH flaw to breach Linux systems · BleepingComputer
- OpenSSH und Alpine Linux warnen vor nischigem, aber gravierendem Bug · heise online
