Auch geschrieben als sshole und sshhole · CVE-2026-123158 · OpenSSH-Server unter Linux mit musl, ohne PAM
Am 5. November 2026 hat das OpenSSH-Projekt Portable OpenSSH 10.6p2 veröffentlicht. Es schließt eine Lücke, über die sich Angreifer ohne Passwort per SSH anmelden: auf Linux-Systemen mit der C-Bibliothek musl, deren SSH-Server Passwörter ohne PAM prüft, etwa unter Alpine Linux. Dort öffnet ein beliebiges Passwort mit 257 bis 1.024 Byte Konten mit einem * im Passwortfeld, sofern ein anderes Konto ein Passwort hat. Systeme mit glibc wie Debian, Ubuntu oder RHEL sind nicht betroffen. Prüfen Sie hier in wenigen Minuten, ob Ihre Server, Container und Geräte betroffen sind, oder lassen Sie VamiSec kurzfristig prüfen.
Selbsttest im BrowserPrüfbefehle ohne ÄnderungenTests nur mit schriftlicher Freigabe
Unabhängige Analyse der VamiSec GmbH, nicht verbunden mit dem OpenSSH-Projekt, Alpine Linux oder dem Entdecker der Lücke. Die Originalanalyse steht auf sshhole.com.
257 Byteab dieser Passwortlänge scheitert crypt() in musl und meldet „*“
1 Zeichenein „*“ im Passwortfeld macht ein Konto ohne Passwort zum Ziel
8.1CVSS 3.1 im CVE-Eintrag, Schweregrad hoch
2016seit OpenSSH 7.3p1 steckt der Fehler im Code
< 2 Tagevon der Meldung bis zum Release von OpenSSH 10.6p2
Auf einen Blick
Der 7-Punkte-Plan gegen *sshole
Von außen nach innen: Machen Sie zuerst sichtbar, welche SSH-Dienste Passwörter annehmen, schalten Sie die Passwort-Anmeldung dort ab und patchen Sie parallel. Danach folgen interne Systeme, Images und Geräte. Lieferkette, Spurensuche und Dokumentation laufen von Tag 1 an mit.
Alle erreichbaren SSH-Dienste erfassen: Server, Bastion-Hosts, Container mit sshd, Router und Geräte. Markieren, welche auf musl laufen und Passwörter annehmen.
Außen · sofort
Passwort-Anmeldung abschalten
Auf musl-Systemen ohne PAM PasswordAuthentication no setzen, vorher den Schlüssel-Login testen, sshd prüfen und neu starten. Das schließt die Lücke sofort.
Außen · parallel
Patchen und neu starten
OpenSSH 10.6p2 oder die gefixten Alpine-Pakete einspielen, sshd neu starten, Images neu bauen. Ein Paket-Update allein ersetzt den laufenden Dienst nicht.
Erst wenn extern erledigt
Innen · danach
Images und Konten nachziehen
Interne Server, Container-Images, Golden Images und Cloud-Vorlagen aktualisieren. Konten mit * im Passwortfeld und Konten mit Passwort-Hash erfassen.
Lieferkette · ab Tag 1
Hersteller fragen
Hersteller von Routern, Appliances und Geräten auf Basis von OpenWrt, Buildroot oder Yocto schriftlich nach Betroffenheit, Patch-Stand und Nachweis fragen.
Ergänzend · begleitend
Spuren suchen
Logs nach Passwort-Anmeldungen an Konten ohne Passwort durchsuchen, doas, neue Konten und SSH-Schlüssel prüfen.
Begleitend
Dokumentieren und melden
Inventar, Patch-Zeitpunkte und Befunde festhalten, bei Hinweisen auf eine Ausnutzung die Meldepflichten nach NIS2, DSGVO, DORA und CRA prüfen.
*sshole ist der Name für CVE-2026-123158, eine Lücke im OpenSSH-Server sshd auf Linux-Systemen mit der C-Bibliothek musl, wenn sshd Passwörter ohne PAM prüft. Für Konten, deren Passwortfeld nur einen Stern * enthält, akzeptiert sshd dann jedes Passwort mit 257 bis 1.024 Byte. Dahinter steckt das Zusammenspiel zweier Entscheidungen: musl meldet einen Fehler beim Passwort-Hashing mit der Zeichenkette *, und sshd vergleicht genau diese mit dem gespeicherten *.
Folge: Wer den SSH-Port erreicht und den Namen eines solchen Kontos kennt, meldet sich ohne Passwort an. In den offiziellen Cloud-Images von Alpine führt das über das Konto alpine und doas ohne Passwort bis zu root-Rechten, sobald irgendein Konto auf der Maschine ein Passwort hat.
Voraussetzungen: musl, sshd ohne PAM, Passwort-Anmeldung aktiv (OpenSSH-Standard), ein Konto mit genau * im Passwortfeld und ein weiteres lokales Konto mit passendem Passwort-Hash, typischerweise SHA ($5$ oder $6$). Fehlt eine davon, greift die Lücke nicht.
Nicht betroffen: Debian, Ubuntu, RHEL, Fedora und andere Systeme mit glibc, Systeme, die Passwörter über PAM prüfen, Dropbear, OpenBSD und Container ohne laufenden sshd.
Abhilfe: OpenSSH 10.6p2 oder die gefixten Pakete der Distribution einspielen und sshd neu starten. Sofort wirksam ist PasswordAuthentication no, wenn der Schlüssel-Login vorher getestet ist.
Prüfung: VamiSec ermittelt kurzfristig von außen, welche Ihrer SSH-Dienste Passwörter annehmen, und von innen, welche Systeme, Images und Geräte die Voraussetzungen erfüllen.
Die Reihenfolge folgt dem Risiko, von außen nach innen. Außen heißt bei *sshole: jeder SSH-Dienst, den ein Angreifer erreichen kann, aus dem Internet, aus Partnernetzen oder aus einem bereits übernommenen Netzsegment. Die wirksamste Sofortmaßnahme kostet Minuten: die Passwort-Anmeldung abschalten.
Außen · sofortPunkt 1
Sichtbarkeit schaffen
Erfassen Sie alle SSH-Dienste, beginnend mit denen, die aus dem Internet erreichbar sind: Server, Bastion-Hosts, Container und Pods mit eigenem sshd, CI-Runner, Router, Firewalls, NAS und andere Geräte. Für jeden Dienst zählen drei Fragen: Läuft OpenSSH auf musl? Prüft sshd Passwörter ohne PAM? Nimmt er überhaupt Passwörter an?
Ob ein Server Passwörter anbietet, zeigt ein Verbindungsaufbau ohne Anmeldung (Prüfbefehle). Die Versionskennung im SSH-Banner ist nur ein Indiz: Sie verrät die Distribution nicht zuverlässig, und gepatchte Alpine-Pakete melden weiter ihre alte OpenSSH-Version.
Außen · sofortPunkt 2
Passwort-Anmeldung abschalten
Setzen Sie auf allen musl-Systemen ohne PAM PasswordAuthentication no und starten Sie sshd neu. Das schließt die Lücke vollständig, auch vor dem Update. Testen Sie vorher, dass die Anmeldung per Schlüssel funktioniert, und halten Sie die laufende Sitzung offen, bis eine neue Anmeldung gelingt.
Zwei Fallen: Alpine liest Drop-in-Dateien unter /etc/ssh/sshd_config.d/ erst ab 3.19, und ein Match-Block kann die Passwort-Anmeldung für einzelne Nutzer wieder einschalten. Die Befehle von Alpine berücksichtigen beides (Übergangsmaßnahmen).
Außen · parallelPunkt 3
Patchen und neu starten
Spielen Sie OpenSSH 10.6p2 oder die gefixten Pakete Ihrer Distribution ein, unter Alpine mit apk upgrade -U -a. Starten Sie sshd danach neu, unter Alpine mit rc-service sshd restart: Ein Paket-Update ersetzt den laufenden Dienst nicht. Container-Images mit sshd bauen Sie neu und rollen sie aus.
Prüfen Sie den Paketstand, nicht die Versionsausgabe von sshd. Alpine hat den Fix in seine stabilen Zweige zurückportiert, dort meldet sshd weiter etwa OpenSSH_10.3p1. Welche Pakete den Fix enthalten, zeigt die Versionstabelle.
Außen · bis zum PatchPunkt 3
Übergangsschutz, wo Passwörter bleiben müssen
Brauchen einzelne Nutzer Passwörter, etwa bei einem SFTP-Dienst, schalten Sie die Passwort-Anmeldung zumindest für alle Konten ohne Passwort ab, zum Beispiel mit einem Match-Block. Alternativ prüft PAM die Passwörter: Alpine nennt openssh-server-pam mit UsePAM yes als nicht betroffen. Begrenzen Sie den SSH-Zugang zusätzlich auf bekannte Netze, ein VPN oder einen Bastion-Host.
Erst wenn alle von außen erreichbaren SSH-Dienste keine Passwörter mehr annehmen oder gepatcht sind, geht es nach innen.
Innen · schrittweisePunkt 4
Images und Konten nachziehen
Aktualisieren Sie danach interne Server, Container-Images, Golden Images und Cloud-Vorlagen. Erfassen Sie, welche Konten genau * im Passwortfeld haben und welche lokalen Konten einen Passwort-Hash tragen. Ein einziges Konto mit Passwort genügt, damit alle Konten ohne Passwort angreifbar werden. Nutzer aus Verzeichnisdiensten, die über musl-nscd eingebunden sind, zählen laut Alpine ebenfalls als Ziel, weil sie keinen Eintrag in /etc/shadow haben.
Lieferkette · ab Tag 1Punkt 5
Hersteller fragen
musl und OpenSSH ohne PAM sind in eingebetteten Systemen verbreitet. OpenWrt nutzt musl, Buildroot und Yocto können damit bauen, und mit ihnen entsteht Firmware für Router, Gateways, Appliances und Industriegeräte. Lieferanten, die nicht von sich aus informiert haben, bitten Sie schriftlich um einen Bericht: Nutzt das Produkt OpenSSH auf musl ohne PAM? Ist Passwort-Anmeldung möglich? Wann kommt ein Update, mit welchem Nachweis? Für Einrichtungen unter NIS2 und Finanzunternehmen unter DORA gehört das Steuern von Lieferkettenrisiken ohnehin zu den Pflichten.
BegleitendPunkt 6
Auf Angriffsspuren prüfen
Durchsuchen Sie die Logs von sshd nach Accepted password for bei Konten, die gar kein Passwort haben, etwa alpine, root oder reine Schlüssel-Konten. Unter Alpine stehen diese Einträge in /var/log/messages. Prüfen Sie auf exponierten Systemen die Nutzung von doas, neu angelegte Konten, Dateien und authorized_keys. Lässt sich eine Anmeldung nicht ausschließen, behandeln Sie das System als kompromittiert. So empfiehlt es auch Alpine. Merkmale im Abschnitt Erkennung.
Bei HinweisenPunkt 6
Neu aufsetzen und Zugangsdaten tauschen
Wer per SSH auf einem System war, kann Schlüssel, Tokens und Passwörter mitgenommen und Hintertüren hinterlassen haben. Setzen Sie betroffene Systeme aus vertrauenswürdigen Quellen neu auf, tauschen Sie SSH-Schlüssel, Zugangsdaten und Tokens, die dort lagen, und prüfen Sie, ob der Angreifer von dort weitere Systeme erreicht hat.
BegleitendPunkt 7
Dokumentieren und Meldepflichten prüfen
Halten Sie Inventar, Patch-Zeitpunkte, Lieferantenantworten und Befunde fest. Bei Hinweisen auf eine Ausnutzung prüfen Sie die Meldepflichten nach NIS2, DSGVO, DORA oder CRA.
Übergangsmaßnahme · Alpine und andere musl-Systeme
Passwort-Anmeldung abschalten
Die Befehle aus dem Alpine-Advisory legen eine Drop-in-Datei an, stellen jede Zeile PasswordAuthentication in /etc/ssh/sshd_config auf no, auch in Match-Blöcken, und sichern das Original als sshd_config.bak. Als root ausführen, Schlüssel-Login vorher testen:
Die letzte Zeile muss passwordauthentication no ausgeben. Rückgängig: Drop-in-Datei löschen und sshd_config.bak zurückkopieren.
Übergangsmaßnahmen · wenn Passwörter bleiben müssen
Angriffsfläche verkleinern
Passwort-Anmeldung nur für Konten zulassen, die wirklich ein Passwort brauchen, für alle anderen per Match-Block mit PasswordAuthentication no abschalten
Passwörter über PAM prüfen lassen: unter Alpine mit openssh-server-pam und UsePAM yes. Ohne UsePAM yes ist auch dieses Paket betroffen, der OpenSSH-Standard ist no
SSH nur aus bekannten Netzen, über VPN oder einen Bastion-Host erreichbar machen
PermitRootLogin nicht auf yes setzen. Die Vorgabe prohibit-password schützt root vor der direkten Anmeldung
Container nur dann mit sshd betreiben, wenn es wirklich nötig ist. Ohne laufenden sshd besteht die Lücke nicht
Diese Maßnahmen verkleinern die Angriffsfläche, ersetzen aber das Update nicht. Prüfen Sie jede Änderung mit einer zweiten Sitzung, bevor Sie die erste schließen.
02 · Überblick
Was hinter *sshole steckt
Der Name spielt mit dem Zeichen, um das es geht: dem Stern im Passwortfeld von /etc/shadow. Seit Jahrzehnten steht dort ein * für ein Konto ohne nutzbares Passwort. Kein Passwort sollte dazu passen. Solche Konten sind häufig: Unter Alpine Linux trägt root im Basis-Image seit etwa Version 3.16 einen Stern, ebenso Konten, die nur per SSH-Schlüssel genutzt werden, und das Konto alpine in den offiziellen Cloud-Images.
Gefunden hat die Lücke Özgün Kültekin von Wakefield. Nach eigener Darstellung baute Kültekin sshd in allen denkbaren Varianten, mit glibc und musl, mit und ohne PAM, mit und ohne Shadow-Passwörter, und ließ Agenten-Schwärme rund 17.600 ungewöhnliche Anmeldeversuche dagegen ausführen. Auffällig wurde dabei die Kombination musl ohne PAM. Am 3. November ging die Meldung an das OpenSSH-Projekt, am 5. November erschien OpenSSH 10.6p2, und Alpine stellte laut Entdecker in derselben Minute gepatchte Pakete bereit.
Das OpenSSH-Projekt sieht die eigentliche Ursache außerhalb von sshd, hat die Lücke aber dort entschärft, wo sie ausnutzbar ist. OpenSSH-Entwickler Damien Miller riet Betreibern betroffener Systeme, sofort die Passwort-Anmeldung oder SSH ganz abzuschalten. Lange Sperrfristen bis zur Veröffentlichung hält das Team laut Miller inzwischen für gefährlich, weil KI-Agenten gemeldete Fehler teils binnen Stunden erneut finden. Zwischen Meldung und Release lagen deshalb weniger als zwei Tage.
Der Fall zeigt, wie sich das Tempo verschiebt. Schon in den Versionshinweisen zu OpenSSH 10.5 und 10.6 berichtete das Projekt von vielen Fehlermeldungen, die von KI-Modellen stammen oder mit KI-Hilfe entstanden sind. Mehrfach wurden KI-gefundene Fehler danach unabhängig erneut entdeckt. Das Projekt kündigte deshalb häufigere Releases an. Für Betreiber heißt das: Zwischen Veröffentlichung und ersten Angriffsversuchen bleibt immer weniger Zeit. Wer nicht weiß, wo welche Version mit welcher Konfiguration läuft, verliert sie mit der Suche.
Anmeldung ohne Passwort
Wer den SSH-Port erreicht und den Namen eines Kontos mit * kennt, meldet sich mit einem beliebigen Passwort von 257 bis 1.024 Byte an. Laut Alpine braucht es dafür eine einzige Verbindung, und es klappt jedes Mal. Der Angreifer erhält eine Sitzung mit den Rechten dieses Kontos.
Bis root über doas
Die offiziellen tiny-cloud-Images von Alpine 3.18.11 bis 3.24.3 liefern das Konto alpine mit * und doas ohne Passwort aus. Sicher sind sie nur, solange kein Konto auf der Maschine ein Passwort hat. Setzt ein Admin etwa ein Konsolen-Passwort, wird aus dem Login als alpine ein Weg zu root.
root direkt meist geschützt
root trägt unter Alpine ebenfalls einen Stern, ist aber durch die OpenSSH-Vorgabe PermitRootLogin prohibit-password vor der direkten Anmeldung mit Passwort geschützt. Direkt angreifbar wird root erst mit PermitRootLogin yes. Über andere Konten mit doas oder sudo führt der Weg auch so dorthin.
03 · Schwachstelle
Eine CVE, fünf Voraussetzungen
Die CVE-Nummer hat MITRE vergeben, nicht das OpenSSH-Projekt. Ob ein System angreifbar ist, entscheidet nicht die OpenSSH-Version allein, sondern das Zusammenspiel aus C-Bibliothek, Build, Konfiguration und Konten.
Beschreibung im CVE-Eintrag · CNA MITRE · veröffentlicht am 05.11.2026
CVE-2026-123158: Umgehung der Passwortprüfung in sshd auf musl ohne PAM
Laut CVE-Eintrag fehlt sshd in OpenSSH vor 10.6p2 unter Linux mit musl und ohne PAM eine Absicherung gegen das Umgehen der Passwort-Anmeldung, weil eine Zeichenkette fälschlich als Passwort-Hash gedeutet wird. Bei manchen Kontokonfigurationen gilt dann ein beliebiges sehr langes Passwort als richtig. Der Eintrag nennt 256 bis 1.024 Zeichen, die Tests des Entdeckers und von Alpine zeigen 257 bis 1.024 Byte. Als Beispiel nennt der Eintrag Alpine Linux.
Betroffen: sshd in OpenSSH vor 10.6p2 unter Linux mit musl, wenn Passwörter ohne PAM geprüft werden. Entstanden ist der Fehler 2016 mit OpenSSH 7.3p1. Der Entdecker hat ihn bis zurück zu OpenSSH 7.5p1 mit musl 1.1.16 aus dem Jahr 2017 nachgewiesen.
Behoben: OpenSSH 10.6p2 mit dem Commit „avoid password authn bypass“, dazu zurückportierte Pakete in Alpine 3.16 bis 3.24 und edge
Fehlerklasse laut CVE-Eintrag: unerwarteter Rückgabewert (CWE-394). Red Hat ordnet die Lücke CWE-303 zu, einem fehlerhaft umgesetzten Authentifizierungsverfahren
Gefunden von: Özgün Kültekin, Wakefield
CVSS 3.1 8.1CWE-394CISA SSVC: PoC · total
Zum CVSS-Wert: MITRE bewertet die Lücke mit 8.1 nach CVSS 3.1 (Vektor AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H). Der Angriff läuft über das Netz, ohne Rechte und ohne Mitwirkung eines Nutzers. Die hohe Angriffskomplexität AC:H spiegelt die Voraussetzungen wider. Sind sie erfüllt, braucht der Angriff keinerlei Exploit-Technik: Ein langes Passwort genügt. OpenSSH selbst spricht von einer kritischen Lücke. Die US-Behörde CISA hält in ihrer Einordnung vom 5. November fest: Proof of Concept vorhanden, nicht automatisierbar, vollständige technische Wirkung.
Die fünf Voraussetzungen
Angreifbar ist ein System nur, wenn alle fünf Punkte zutreffen. Zusätzlich muss der Angreifer den SSH-Port erreichen und den Namen eines Zielkontos kennen. Namen wie root, alpine oder git sind leicht zu raten.
Voraussetzungen für *sshole laut Alpine-Advisory, OpenSSH und Entdecker (Stand 06.11.2026)
Voraussetzung
Was das bedeutet
So prüfen Sie es
1 · C-Bibliothek musl
Alpine Linux, OpenWrt, postmarketOS, Void Linux (musl), Chimera Linux, dazu Firmware aus Buildroot oder Yocto, wenn sie mit musl gebaut ist. Nicht betroffen sind Systeme mit glibc wie Debian, Ubuntu, RHEL, Fedora und SUSE.
ls /lib/ld-musl-*.so.1
2 · sshd prüft Passwörter ohne PAM
Das Alpine-Paket openssh-server ist ohne PAM gebaut. openssh-server-pam ist nur mit UsePAM yes geschützt, der OpenSSH-Standard ist no.
sshd -T | grep -i usepam keine Ausgabe: sshd ohne PAM gebaut
3 · Passwort-Anmeldung aktiv
PasswordAuthentication yes ist der OpenSSH-Standard, wenn nichts anderes konfiguriert ist. Images, die per cloud-init eingerichtet werden, schalten sie laut Alpine ab.
sshd -T | grep -i passwordauthentication
4 · Zielkonto mit genau *
Unter Alpine root (aber durch PermitRootLogin geschützt), Schlüssel-Konten ohne Passwort, Nutzer aus Verzeichnisdiensten über musl-nscd, das Konto alpine in den Cloud-Images. Gesperrte Konten mit ! sind nicht betroffen.
awk -F: '$2=="*"{print $1}' /etc/shadow
5 · Salt-Spender mit Passwort-Hash
Ein anderes lokales Konto mit Passwort-Hash, typischerweise SHA ($5$, $6$). Ein einziger Nutzer mit Passwort genügt. Genau genommen zählt laut IONIX das erste Konto mit Hash in /etc/passwd: bcrypt ($2…$) wirkt vor 10.6p2 sogar mit kurzem Passwort, MD5 ($1$) und yescrypt ($y$) nicht.
awk -F: '$2 ~ /^\$[56]\$/{print $1}' /etc/shadow
Alle Befehle als root ausführen, sie ändern nichts. Unter Alpine heißt das Programm bei openssh-server-pamsshd.pam. Weitere Befehle stehen bei den Prüfbefehlen, die Bewertung übernimmt der Selbsttest.
04 · Technischer Hintergrund
So wird aus einem langen Passwort ein Schlüssel
Ohne PAM prüft sshd ein Passwort selbst: Es hasht den eingegebenen Wert mit der C-Funktion crypt() und vergleicht das Ergebnis mit dem gespeicherten Feld. Zwei für sich genommen vernünftige Entscheidungen aus den Jahren 2012 und 2016 ergeben zusammen die Lücke.
Eingabe
Langes Passwort
Der Angreifer meldet sich an einem Konto mit * an und sendet ein Passwort mit 257 bis 1.024 Byte, zum Beispiel 300 Mal den Buchstaben A.
Geliehenes Salt
Kein Salt im Stern
Ein * enthält kein Salt. Seit 2016 leiht sich sshd dann das Salt eines anderen Kontos, damit die Antwortzeit nicht verrät, ob es ein Konto gibt.
Fehler als Wert
crypt() meldet „*“
musl hasht mit SHA-crypt höchstens 256 Byte. Bei längeren Eingaben scheitert crypt() und liefert als Fehlerzeichen die Zeichenkette * zurück.
Wirkung
„*“ gleich „*“
sshd vergleicht das vermeintliche Ergebnis * mit dem gespeicherten *. Beide sind gleich, die Anmeldung gilt als erfolgreich.
Vereinfachte Darstellung nach den Release Notes von OpenSSH 10.6p2, dem Fix-Commit, dem Alpine-Advisory und der Analyse des Entdeckers. Über 1.024 Byte weist sshd ein Passwort ab, bevor es crypt() erreicht.
Ursache in musl · 2012
Ein Fehler, der wie ein Hash aussieht
musl gibt bei einem Fehler in crypt() seit August 2012 die Zeichenkette * zurück statt eines Nullzeigers. Das sollte Programme schützen, die das Ergebnis nicht prüfen, denn zu einem * passt normalerweise kein gespeicherter Hash. Kurz darauf kam SHA-crypt mit einer Obergrenze von 256 Byte für das Passwort hinzu. glibc und libxcrypt melden Fehler anders, mit einem Nullzeiger oder *0, nie mit einem einzelnen *.
Ursache in OpenSSH · 2016
Das geliehene Salt
Gegen CVE-2016-6210, das Erraten gültiger Nutzernamen über die Antwortzeit, hasht sshd seit OpenSSH 7.3p1 auch bei Konten ohne nutzbaren Hash. Ist das gespeicherte Feld zu kurz für ein Salt, nimmt die Funktion pick_salt() das Salt des ersten Kontos mit echtem Hash. Den Vergleich mit dem gespeicherten Feld behielt sshd bei. Genau dieser Vergleich trifft nun auf den Stern von musl.
Fix · OpenSSH 10.6p2
Mindestens vier Zeichen
Der Commit „avoid password authn bypass“ lässt einen Vergleich nur noch zu, wenn der gespeicherte Hash mindestens vier Zeichen lang ist. Ein einzelner * kann damit nie mehr passen, egal welches Salt sshd verwendet. Zusätzlich arbeitet sshd jetzt mit eigenen Kopien der Passwortfelder statt mit Zeigern in statische Puffer der C-Bibliothek. Das Projekt nennt den Fix ausdrücklich eine Behelfslösung (Workaround) in sshd, die Ursache liege außerhalb.
Praxis · für Prüfer
Eine Verbindung, zwei Versuche
Der öffentliche Proof of Concept des Entdeckers sendet in einer Verbindung zuerst ein beliebiges falsches und dann ein 300 Zeichen langes Passwort. Laut einer Laboranalyse von IONIX scheitert der erste Versuch je Verbindung am Zustand eines internen Puffers. Prüfwerkzeuge, die nur einen Versuch je Verbindung senden, können verwundbare Systeme deshalb übersehen. Ebenfalls laut IONIX genügt vor 10.6p2 sogar ein kurzes Passwort, wenn das erste Konto mit Hash einen bcrypt-Hash trägt. Auch diesen Fall schließt 10.6p2.
05 · Betroffenheit
Welche Systeme betroffen sind
Entscheidend ist nicht die Distribution allein, sondern ob sshd auf musl läuft und Passwörter ohne PAM prüft. Alpine hat den Fix in seine stabilen Zweige zurückportiert, ohne die OpenSSH-Version zu ändern. Maßgeblich ist deshalb der Paketstand, nicht die Ausgabe von sshd -V.
Alpine Linux: gefixte Pakete je Zweig laut Alpine-Advisory vom 05.11.2026. Die Spalte „sshd meldet“ ist aus der Upstream-Version abgeleitet.
Zweig
Fix ab Paket openssh
sshd meldet
Hinweis
edge
10.6_p2-r0
OpenSSH_10.6p2
Entwicklungszweig mit der neuen OpenSSH-Version
3.24
10.3_p1-r2
OpenSSH_10.3p1
enthalten ab Point-Release 3.24.4
3.23
10.2_p1-r1
OpenSSH_10.2p1
enthalten ab Point-Release 3.23.8
3.22
10.0_p1-r11
OpenSSH_10.0p1
enthalten ab Point-Release 3.22.8
3.21
9.9_p2-r1
OpenSSH_9.9p2
enthalten ab Point-Release 3.21.10. Der Support für 3.21 endete am 01.11.2026
3.20
9.7_p1-r6
OpenSSH_9.7p1
ohne regulären Support, Fix trotzdem bereitgestellt
3.19
9.6_p1-r3
OpenSSH_9.6p1
ohne regulären Support, Fix trotzdem bereitgestellt
3.18
9.3_p2-r4
OpenSSH_9.3p2
ohne regulären Support, Fix trotzdem bereitgestellt
3.17
9.1_p1-r7
OpenSSH_9.1p1
ohne regulären Support, Fix trotzdem bereitgestellt
3.16
9.0_p1-r6
OpenSSH_9.0p1
ohne regulären Support, Fix trotzdem bereitgestellt
Die offiziellen Cloud-Images (tiny-cloud) ab 3.21.10, 3.22.8, 3.23.8 und 3.24.4 enthalten das gefixte Paket. Laufende Instanzen aus älteren Images müssen Sie selbst aktualisieren oder die Passwort-Anmeldung abschalten. Die Point-Releases sind nicht dasselbe wie die Paketversionen: Ob ein System den Fix hat, zeigt apk info -v | grep '^openssh'. sshd -V gibt es erst ab OpenSSH 9.2, auf älteren Systemen steht die Version in der Hilfeausgabe.
Weitere Plattformen und Produkte
Einschätzung weiterer Plattformen nach Herstellerangaben, Paketquellen und Analysen (Stand 06.11.2026)
Plattform
Einschätzung
Hinweis
Debian, Ubuntu, RHEL, Fedora, SUSE, Amazon Linux
nicht betroffen (glibc)
glibc und PAM. Laut OpenSSH besteht die Lücke auf Linux-Systemen mit glibc und auf Systemen, die Passwörter über PAM prüfen, nicht. Red Hat erklärt seine Produkte ausdrücklich für nicht betroffen.
OpenBSD, FreeBSD, macOS, Windows
nicht betroffen
Laut OpenSSH betrifft die Lücke nur Linux.
Dropbear
nicht betroffen
Eigene SSH-Implementierung, Standard-SSH-Server von OpenWrt und vielen Geräten.
OpenWrt mit Paket openssh-server
möglich
Das Paket ist ohne PAM gebaut. Betroffen, wenn es installiert ist und die übrigen Voraussetzungen erfüllt sind. Der master-Zweig des Paket-Feeds führt bereits 10.6p2, die Variante openssh-server-pam prüft über PAM.
Buildroot, Yocto, eigene Firmware
möglich
Betroffen, wenn die Firmware mit musl gebaut ist und OpenSSH ohne PAM prüft. Buildroot baut OpenSSH ohne PAM, solange Linux-PAM nicht ausgewählt ist, und führt im Entwicklungsstand bereits 10.6p2. Fragen Sie den Hersteller nach dem Stand Ihres Geräts.
Weitere musl-Distributionen
möglich
postmarketOS, Void Linux (musl), Chimera Linux und andere: betroffen nur, wenn sshd Passwörter ohne PAM prüft. Hinweise des jeweiligen Projekts beachten.
Container-Images mit sshd
möglich
Nur betroffen, wenn im Container ein sshd läuft. Alpine-basierte Images für SFTP, Git oder Debug-Zugänge prüfen, auch solche mit openssh-server-pam, wenn UsePAM yes nicht ausdrücklich gesetzt ist. Images ohne sshd sind nicht betroffen.
Alpine-Cloud-Images (tiny-cloud)
exponiert, sobald ein Passwort existiert
Images von 3.18.11 bis 3.24.3: Konto alpine mit * und doas ohne Passwort. Sicher beim ersten Start, angreifbar ab dem ersten $6$-Hash auf der Maschine. Per cloud-init eingerichtete Images setzen laut Alpine PasswordAuthentication no.
Selbsttest: Ist dieses System angreifbar?
Beantworten Sie die Fragen für einen SSH-Server. Die Antworten liefern die Befehle aus der Tabelle der Voraussetzungen oder die Prüfbefehle. Das Ergebnis erscheint sofort.
Exponiert heißt: Jeder, der den Port erreicht und einen Kontonamen kennt, kann sich anmelden.
Derzeit nicht ausnutzbar heißt: Eine Voraussetzung fehlt, das kann sich mit dem nächsten Konto oder Passwort ändern.
Nicht betroffen heißt: Die Lücke kann auf diesem System nicht auftreten.
Der Selbsttest läuft vollständig im Browser, es wird nichts übertragen oder gespeichert. Er ersetzt keine Prüfung aller Systeme und keine Herstellerhinweise.
Prüfbefehle für Server und Container
Diese Befehle verändern nichts an Ihren Systemen. Führen Sie sie als root auf dem zu prüfenden System aus, in Containern mit docker exec oder kubectl exec. Den letzten Befehl führen Sie von einem anderen Rechner aus.
# 1. C-Bibliothek: Gibt es den musl-Loader?
ls /lib/ld-musl-*.so.1 2>/dev/null
# 2. und 3. PAM und Passwort-Anmeldung laut aktiver Konfiguration (Alpine mit PAM: sshd.pam -T)
sshd -T | grep -Ei '^(usepam|passwordauthentication|kbdinteractiveauthentication|permitrootlogin) '
# 4. Mögliche Ziele: Konten mit genau "*" im Passwortfeld
awk -F: '$2=="*"{print $1}' /etc/shadow
# 5. Salt-Spender: Konten mit Passwort-Hash in passwd-Reihenfolge, laut IONIX zählt das erste:# $5$/$6$ = ausnutzbar, $2…$ (bcrypt) = vor 10.6p2 auch mit kurzem Passwort, $1$/$y$ = nicht
awk -F: 'NR==FNR{h[$1]=$2; next} h[$1] ~ /^\$/{print $1, substr(h[$1], 1, index(substr(h[$1], 2), "$") + 1)}' /etc/shadow /etc/passwd
# Alpine: Zweig und installierter Paketstand (maßgeblich, nicht sshd -V)
cat /etc/alpine-release
apk info -v 2>/dev/null | grep '^openssh'
# Läuft noch der alte sshd? "(deleted)" heißt: Neustart fehlt
for p in $(pidof sshd); do readlink /proc/$p/exe; done
# Logs: Passwort-Anmeldungen (Alpine: /var/log/messages, sonst auth.log oder Journal)
grep 'Accepted password' /var/log/messages /var/log/auth.log 2>/dev/null
# Von außen: Welche Anmeldeverfahren bietet der Server diesem Nutzer an?
ssh -o PreferredAuthentications=none -o PubkeyAuthentication=no -o BatchMode=yes \
-v NUTZER@HOST 2>&1 | grep 'can continue'
Steht in der letzten Ausgabe password, nimmt der Server für diesen Nutzer Passwörter an. Ein Match-Block kann das je Nutzer ändern, prüfen Sie deshalb die tatsächlich genutzten Kontonamen.
Werkzeuge · Open Source
Prüfskript und Labore des Entdeckers
Der Entdecker stellt im Repository oz9un/sshole unter MIT-Lizenz ein Prüfskript, einen Proof of Concept, eine Laborumgebung mit Alpine 3.24 und den Patch bereit. Das Skript check.sh liest nur und schreibt nichts. Es braucht root-Rechte, weil es /etc/shadow auswertet, und meldet mit Exit-Code 0 exponiert, 1 nicht exponiert und 2 unklar.
Grenze bei Alpine:check.sh erkennt den Fix nur an der sshd-Version 10.6p2 oder neuer. Gepatchte Systeme der Alpine-Zweige 3.16 bis 3.24 meldet es deshalb weiter als exponiert, wenn die übrigen Voraussetzungen erfüllt sind. Maßgeblich ist dort der Paketstand aus der Versionstabelle.
Nachbau-Labore: Der CVE-Eintrag verweist auf zwei weitere Laborumgebungen, predkambrij/sshhole-repro und leonjza/sshhole-lab.
Vorsicht: Lesen Sie fremde Skripte, bevor Sie sie als root ausführen.
Ein Anmeldeversuch mit langem Passwort ist ein Zugriff auf ein fremdes Konto. Testen Sie nur eigene Systeme oder solche, für die eine schriftliche Freigabe vorliegt.
Erfolgreiche Tests hinterlassen echte Sitzungen und Log-Einträge. Stimmen Sie sie mit Betrieb und SOC ab, damit sie nicht als Angriff gewertet werden.
Gleichen Sie jeden Befund mit Paketstand, Konfiguration und Herstellerhinweis ab.
VamiSec unterstützt
Analyse, Recon und Attack Surface Management
Wir prüfen Ihre Systeme, Images und Geräte, werten die Ergebnisse aus und trennen echte Treffer von Fehlalarmen. Ihre externe Angriffsfläche erfassen wir dabei mit VamiRedteam. Die agentische Plattform kartiert Domains, Hosts und exponierte Dienste und arbeitet nur im freigegebenen Umfang: mit signierter Autorisierung, harter Grenze am Scope und lückenlosem Audit-Log.
Eine erfolgreiche Ausnutzung sieht im Log aus wie eine normale Passwort-Anmeldung. Das Passwort und seine Länge protokolliert sshd nicht. Auffällig ist der Zusammenhang: eine Anmeldung per Passwort an einem Konto, das gar kein Passwort hat.
Logs von sshd
Passwort-Anmeldung ohne Passwort
Accepted password for alpine from 203.0.113.7 port 51234 ssh2 oder dieselbe Zeile für root, git und andere Schlüssel-Konten
Unter Alpine in /var/log/messages, sonst in auth.log oder im Journal
Kurz davor gescheiterte Passwort-Versuche aus derselben Quelle
Anmeldungen aus unbekannten Netzen bei Konten, die sonst nur Schlüssel nutzen
Host
Was nach der Anmeldung passiert
doas- oder sudo-Aufrufe durch alpine oder Dienstkonten
Neue Konten, Änderungen an authorized_keys, neue Cronjobs und Dienste
Unbekannte Prozesse und ausgehende Verbindungen
Port-Weiterleitungen über SSH in das interne Netz
Netzwerk
Auffällige SSH-Sitzungen
Viele Verbindungen mit Passwort-Versuchen von einzelnen Quellen
SSH-Sitzungen zu Geräten, die sonst nur selten administriert werden
Tunnel oder Proxy-Verkehr über SSH-Verbindungen von Geräten aus
Rechnen Sie damit, dass Werkzeuge für SSH-Brute-Force lange Passwörter bald routinemäßig mitprobieren.
Grenzen der Spurensuche: Unter Alpine verlassen Sie sich nicht auf last oder who. Laut IONIX sind lastlog und die klassische utmp/wtmp-Protokollierung im Alpine-Build von OpenSSH abgeschaltet. wtmp-Einträge entstehen nur, wenn die utmps-Dienste laufen, und nur bei interaktiven Sitzungen. Maßgeblich sind die Logs von sshd. Liegen sie nur lokal, kann ein Angreifer mit root-Rechten sie löschen. Sammeln Sie Logs deshalb zentral, und spielen Sie das Update ein, auch wenn Sie nichts Auffälliges finden.
Verdacht auf Kompromittierung? Unser CSIRT ist rund um die Uhr unter csirt@vamisec.com erreichbar. Ein Compromise Assessment klärt, ob Angreifer bereits im System sind.
07 · Lage und Hintergrund
Wird *sshole schon ausgenutzt?
Stand ist keine Ausnutzung bekannt. Der Angriff ist aber einfach, Anleitungen und Labore sind öffentlich. Rechnen Sie mit Scans, sobald Angreifer ihre Werkzeuge angepasst haben.
Behörden
Kein KEV-Eintrag, PoC bestätigt
Im Katalog bekannter ausgenutzter Schwachstellen (KEV) der US-Behörde CISA steht CVE-2026-123158 bislang nicht. Der letzte Katalogstand vom 04.11. stammt allerdings von vor der Veröffentlichung. In ihrer Einordnung vom 5. November hält CISA fest: Proof of Concept vorhanden, nicht automatisierbar, vollständige technische Wirkung. Red Hat erklärt seine Produkte für nicht betroffen.
Sicherheitsanbieter
Noch keine Angriffe gemeldet
Detectify war am 5. November keine Ausnutzung bekannt, rechnet aber mit Scans, weil die Details öffentlich sind und der Angriff einfach ist. Jake Knott von watchTowr erwartete gegenüber CSO Online, dass SSH-Brute-Forcer den Trick schon bis zum Wochenende ausprobieren.
Exploit-Code
Kein Exploit nötig
Der Entdecker hat neben dem Prüfskript einen Proof of Concept veröffentlicht. Er meldet sich mit dem Standard-SSH-Client oder einem kurzen Python-Skript und einem 300 Zeichen langen Passwort an. Weitere Labore sind im CVE-Eintrag verlinkt. Für Verteidiger heißt das: nicht auf Meldungen über Angriffe warten.
Warum der Fehler zehn Jahre unentdeckt blieb
Keine der beteiligten Entscheidungen war für sich genommen falsch. musl wollte Abstürze in Programmen verhindern, die das Ergebnis von crypt() nicht prüfen. OpenSSH wollte verhindern, dass Angreifer gültige Nutzernamen über Antwortzeiten erraten. Alpine stellte root 2022 von ! auf * um, damit SSH-Schlüssel für root wieder funktionieren. Erst zusammen ergeben sie die Lücke.
Ende 2024 diskutierte die musl-Mailingliste sogar einen Absturz von busybox passwd mit einem 257 Byte langen Passwort, ohne die Verbindung zu sshd zu ziehen. Gefunden hat die Lücke erst eine Testmatrix über C-Bibliotheken und Build-Optionen, ausgeführt von Agenten-Schwärmen.
Seit OpenSSH 10.5 im August 2026 berichtet das Projekt von vielen KI-gestützten Fehlermeldungen und davon, dass KI-gefundene Fehler unabhängig erneut entdeckt werden. Laut Damien Miller geschieht das teils binnen Stunden. Die Folge sind kürzere Sperrfristen und häufigere Releases. Für Betreiber schrumpft damit die Zeit zwischen Veröffentlichung und Angriff. Wer in Stunden statt in Wochen reagieren will, braucht ein aktuelles Inventar und eingeübte Abläufe.
Zeitleiste
musl lässt crypt() bei Fehlern * zurückgeben und begrenzt SHA-crypt auf 256 Byte.
OpenSSH entschärft CVE-2016-6210 mit dem geliehenen Salt aus pick_salt(), ausgeliefert ab 7.3p1. Die Lücke entsteht.
Alpine 3.16 stellt root von ! auf * um, damit SSH-Schlüssel für root wieder funktionieren.
Auf der musl-Mailingliste fällt der Absturz von busybox passwd mit 257 Byte auf, der Bezug zu sshd nicht.
Özgün Kültekin findet die Lücke mit einer Testmatrix über C-Bibliotheken und Build-Optionen und meldet sie dem OpenSSH-Projekt. Laut Entdecker liegt binnen einer Stunde ein Patch vor.
Alpine und musl werden informiert, der Fix wird im OpenSSH-Quellcode committet.
OpenSSH 10.6p2 erscheint, Alpine liefert gepatchte Pakete für 3.16 bis 3.24 und edge sowie die Point-Releases 3.21.10, 3.22.8, 3.23.8 und 3.24.4. Die Analyse des Entdeckers erscheint, MITRE veröffentlicht die CVE-Nummer.
Breite Berichterstattung in der Fachpresse. Eine Ausnutzung ist bis zum 6. November nicht bekannt.
08 · VamiSec-Betroffenheitsprüfung
Wir prüfen kurzfristig, ob *sshole Sie betrifft
Sie entscheiden, wie tief wir schauen: nur von außen, ohne Zugang zu Ihrer Umgebung, oder zusätzlich von innen mit lesenden Prüfungen auf Servern, Images und Geräten. Am Ende steht eine priorisierte Liste, wo Sie zuerst handeln müssen.
Variante A · von außen
Blackbox-Prüfung
Wir betrachten Ihre Umgebung so, wie ein Angreifer sie aus dem Internet sieht. Sie brauchen uns dafür keinen Zugang zu geben.
Mit Recon und Attack Surface Management von VamiRedteam erfassen wir Ihre erreichbaren SSH-Dienste, ausgehend von Ihren Domains und IP-Bereichen
Für jeden Dienst ermitteln wir ohne Anmeldung, welche Verfahren er anbietet, und markieren Dienste, die Passwörter annehmen
Banner und Fingerabdrücke liefern Indizien für musl-basierte Systeme wie Alpine, OpenWrt oder eingebettete Firmware
Anmeldeversuche mit langem Passwort nur nach gesonderter schriftlicher Freigabe und nur auf Ihren eigenen Systemen
Ergebnis: Liste Ihrer erreichbaren SSH-Dienste mit Passwort-Anmeldung und Risikobewertung. Von außen erhalten Sie Indizien, aber keine Gewissheit über Konten und Paketstände.
Variante B · von innen
Server-, Image- und Kontoprüfung
Wir prüfen lesend auf Ihren Systemen, ohne etwas zu verändern, und gleichen die Ergebnisse mit den gefixten Paketständen ab.
Prüfung von Linux-Servern auf C-Bibliothek, PAM, Passwort-Anmeldung, Konten mit *, Salt-Spender, Paketstand und Neustart von sshd
Container-Images in Registries und laufende Pods mit sshd, dazu Golden Images und Cloud-Vorlagen
Für Cloud-Konten auf Wunsch agentlose Inventur von VMs und Images mit Wiz. VamiSec ist Mitglied der Wiz Partner Alliance
Abgleich mit den Hinweisen von OpenSSH, Alpine und Ihren Herstellern
Ergebnis: belastbares Inventar, welche Systeme exponiert, welche nur durch Konfiguration geschützt und welche gepatcht sind.
Empfohlen · kombiniert
Außen und innen zusammen
Die Kombination beantwortet die entscheidende Frage: Welche exponierten Systeme erreicht ein Angreifer tatsächlich?
Außensicht und Inventar werden zusammengeführt
Angriffspfade vom Internet bis zu Konten mit doas- oder sudo-Rechten
Priorisierter Maßnahmenplan mit Reihenfolge, Übergangsschutz und Nachweisen für Audits
Kontrolle nach dem Patch, ob alle Systeme den Fix haben und sshd neu gestartet wurde
Ergebnis: belastbare Entscheidungsgrundlage für IT, CISO und Geschäftsführung.
01 · Erstgespräch
Umfang klären
In 30 Minuten klären wir Domains, Netze, Cloud-Anbieter, Images, Geräte und Ihre Prioritäten.
02 · Freigabe
Schriftlich autorisieren
Sie geben den Umfang schriftlich frei. Ohne Freigabe testen wir nichts.
03 · Prüfung
Außen- und Innensicht
Wir führen die vereinbarten Prüfungen durch und melden exponierte Systeme sofort.
04 · Ergebnis
Bericht und Maßnahmenplan
Sie erhalten eine Management-Zusammenfassung, die technische Befundliste und die Reihenfolge der Maßnahmen.
Für Hersteller von Geräten
Wir prüfen Firmware auf Basis von OpenWrt, Buildroot oder Yocto: C-Bibliothek, Build-Optionen von OpenSSH, Standardkonten und Passwortfelder
Wir testen Geräte im Rahmen unserer IoT-Pentests und dokumentieren Befunde und Fixes
Wir unterstützen bei der Schwachstellenbehandlung und Meldung nach dem Cyber Resilience Act
So gehen wir vor
Wir arbeiten nur im freigegebenen Umfang und stimmen Testzeitfenster mit Ihnen ab. Systeme, die Dienstleister für Sie betreiben, testen wir aktiv nur mit deren Zustimmung
Anmeldeversuche mit langem Passwort nur nach gesonderter schriftlicher Freigabe und abgestimmt mit Ihrem Betrieb und SOC
Vertraulichkeit regeln wir vorab per NDA, die Verarbeitung von Prüfdaten bei Bedarf per Auftragsverarbeitungsvertrag
Bei Hinweisen auf eine Kompromittierung schalten wir auf Wunsch sofort unser CSIRT ein
Betroffenheitsprüfung anfragen
Buchen Sie direkt ein Erstgespräch oder schreiben Sie an contact@vamisec.com. Wir antworten innerhalb von 24 Stunden. Nennen Sie gern schon Domains, Netze, Cloud-Anbieter und Gerätetypen, dann können wir den Umfang sofort einschätzen.
Eine ungenutzte Schwachstelle allein löst in Deutschland und der EU keine Meldepflicht aus. Das ändert sich, wenn sie bei Ihnen ausgenutzt wurde. Hersteller, die OpenSSH in eigenen Produkten ausliefern, müssen zudem melden, sobald es verlässliche Hinweise auf eine aktive Ausnutzung gibt. Die Fristen beginnen mit der Kenntnis vom Vorfall, nicht mit der Veröffentlichung der CVE. Diese Übersicht ist eine Orientierung und keine Rechtsberatung.
NIS2 · BSI-Gesetz
Wichtige und besonders wichtige Einrichtungen
Schwachstellen zu behandeln und zu patchen ist Teil des Risikomanagements, das das BSI-Gesetz vorschreibt. Melden müssen Sie einen erheblichen Sicherheitsvorfall, etwa einen erfolgreichen unbefugten Zugriff, der den Betrieb schwer stören kann. Dann gilt: Frühwarnung binnen 24 Stunden, Meldung binnen 72 Stunden, Abschlussbericht einen Monat nach der Meldung.
DSGVO
Wenn personenbezogene Daten betroffen sind
Hatte ein Angreifer per SSH Zugriff auf Systeme mit personenbezogenen Daten, melden Sie das der Aufsichtsbehörde unverzüglich und möglichst binnen 72 Stunden, außer es besteht voraussichtlich kein Risiko. Bei hohem Risiko informieren Sie die Betroffenen unverzüglich. Jede Datenpanne ist zu dokumentieren.
Cyber Resilience Act
Hersteller, die OpenSSH in Produkten ausliefern
Seit dem 11. September 2026 müssen Hersteller aktiv ausgenutzte Schwachstellen in ihren Produkten über die Meldeplattform der ENISA melden, auch für bereits verkaufte Produkte. Würde *sshole aktiv ausgenutzt, beträfe das etwa Router, Gateways und Geräte mit OpenSSH auf musl ohne PAM. Fristen: 24 Stunden, 72 Stunden und ein Abschlussbericht 14 Tage nach Verfügbarkeit eines Fixes. Ab dem 11. Dezember 2027 gelten zudem die Pflichten zur Schwachstellenbehandlung für neue Produkte.
DORA
Finanzunternehmen
Banken, Versicherer und andere Finanzunternehmen melden nicht nach dem BSI-Gesetz, sondern nach DORA an ihre Aufsicht. Ein erfolgreicher, böswilliger Zugriff ist dort ein zentrales Kriterium für einen schwerwiegenden IKT-Vorfall. Die Erstmeldung ist binnen 4 Stunden nach der Einstufung fällig, spätestens 24 Stunden nach Kenntnis.
Ein abgewehrter Anmeldeversuch ist in der Regel kein meldepflichtiger Vorfall, sondern allenfalls ein Beinahevorfall. Freiwillige, auch anonyme Meldungen an das BSI sind trotzdem möglich. Vertiefung: NIS2, Cyber Resilience Act, DORA.
10 · FAQ
Häufige Fragen zu *sshole
Was ist *sshole?
*sshole ist der Name für CVE-2026-123158, eine Lücke im OpenSSH-Server sshd auf Linux-Systemen mit der C-Bibliothek musl, die Passwörter ohne PAM prüfen. Für Konten, deren Passwortfeld nur einen Stern enthält, akzeptiert sshd dort jedes Passwort mit 257 bis 1.024 Byte. Behoben ist die Lücke in OpenSSH 10.6p2 vom 5. November 2026 und in zurückportierten Paketen der Distributionen.
Warum heißt die Lücke *sshole?
Der Name spielt mit dem Stern, um den es geht: dem * im Passwortfeld von /etc/shadow, der ein Konto ohne nutzbares Passwort kennzeichnet. Der Entdecker Özgün Kültekin veröffentlicht die Analyse unter sshhole.com, in der Presse kursieren auch sshole und sshhole. Gemeint ist immer CVE-2026-123158.
Bin ich von *sshole betroffen?
Nur wenn fünf Dinge zusammenkommen: sshd läuft auf musl, prüft Passwörter ohne PAM, die Passwort-Anmeldung ist aktiv, es gibt ein Konto mit genau * im Passwortfeld, und ein weiteres lokales Konto hat einen Passwort-Hash, typischerweise SHA mit $5$ oder $6$. Typisch ist das bei Alpine Linux mit dem Paket openssh-server. Der Selbsttest auf dieser Seite bewertet Ihre Antworten sofort.
Sind Debian, Ubuntu oder Red Hat betroffen?
Nein. Diese Distributionen nutzen glibc und prüfen Passwörter über PAM. Laut OpenSSH besteht die Lücke auf Linux-Systemen mit glibc und auf Systemen, die PAM für die Passwortprüfung nutzen, nicht. Red Hat erklärt seine Produkte ausdrücklich für nicht betroffen.
Ist ein Alpine-Container automatisch betroffen?
Nein. Ein Container ist nur betroffen, wenn darin ein sshd läuft und die übrigen Voraussetzungen erfüllt sind. Die meisten Alpine-basierten Images enthalten keinen SSH-Server. Prüfen Sie aber Images, die bewusst SSH anbieten, etwa für SFTP, Git oder Debug-Zugänge.
Ist ein Konto mit * im Passwortfeld gesperrt?
Nicht im Sinne von OpenSSH. Ein * bedeutet: Es gibt kein nutzbares Passwort, eine Anmeldung per SSH-Schlüssel bleibt möglich. Gesperrt im Sinne von OpenSSH sind Konten, deren Passwortfeld mit ! beginnt. Sie lassen weder Passwort noch Schlüssel zu und sind von *sshole nicht betroffen. Ein * durch ! zu ersetzen sperrt deshalb auch den Schlüssel-Zugang.
Kann ein Angreifer root werden?
Direkt meist nicht: root trägt unter Alpine zwar einen Stern, ist aber durch die Vorgabe PermitRootLogin prohibit-password vor der Anmeldung mit Passwort geschützt. Über andere Konten geht es trotzdem. In den offiziellen Alpine-Cloud-Images von 3.18.11 bis 3.24.3 hat das Konto alpine einen Stern und darf doas ohne Passwort nutzen. Sobald ein Konto auf der Maschine ein Passwort hat, führt der Weg so bis zu root.
Welche Versionen sind sicher?
OpenSSH 10.6p2 und neuer. Unter Alpine enthalten die Pakete openssh 10.6_p2-r0 (edge), 10.3_p1-r2 (3.24), 10.2_p1-r1 (3.23), 10.0_p1-r11 (3.22), 9.9_p2-r1 (3.21), 9.7_p1-r6 (3.20), 9.6_p1-r3 (3.19), 9.3_p2-r4 (3.18), 9.1_p1-r7 (3.17) und 9.0_p1-r6 (3.16) den Fix. In den stabilen Zweigen meldet sshd weiter die alte OpenSSH-Version, maßgeblich ist der Paketstand.
Reicht PasswordAuthentication no als Schutz?
Ja, als Übergang. Ohne Passwort-Anmeldung ist die Lücke nicht ausnutzbar. Prüfen Sie, dass kein Match-Block Passwörter für einzelne Nutzer wieder erlaubt, und beachten Sie, dass Alpine vor 3.19 Drop-in-Dateien nicht liest. Testen Sie vorher den Schlüssel-Login und spielen Sie das Update trotzdem ein.
Muss ich sshd nach dem Update neu starten?
Ja. Laut Alpine ersetzt ein Paket-Update den laufenden sshd nicht. Starten Sie sshd neu, unter Alpine mit rc-service sshd restart, und rollen Sie Container mit neu gebauten Images aus. Zeigt readlink /proc/PID/exe für den sshd-Prozess „(deleted)“, läuft noch die alte Datei.
Warum meldet sshd nach dem Update die alte Version?
Weil Alpine den Fix in seine stabilen Zweige zurückportiert hat, ohne die OpenSSH-Version zu ändern. Auf Alpine 3.24 meldet sshd mit Fix weiter OpenSSH_10.3p1. Ob der Fix installiert ist, zeigt der Paketstand, etwa openssh-server-10.3_p1-r2. Prüfskripte, die nur die sshd-Version auswerten, melden gepatchte Alpine-Systeme deshalb fälschlich als exponiert.
Wird *sshole bereits aktiv ausgenutzt?
Stand 6. November 2026 ist keine Ausnutzung bekannt, und CISA führt die Lücke bislang nicht im KEV-Katalog. Der Angriff braucht aber keine Exploit-Technik, ein Proof of Concept ist öffentlich, und Fachleute rechnen kurzfristig mit Scans. Behandeln Sie erreichbare Systeme deshalb so, als würden sie angegriffen.
Gibt es einen Scanner oder Proof of Concept?
Ja. Der Entdecker stellt im Repository oz9un/sshole ein lesendes Prüfskript, einen Proof of Concept, eine Laborumgebung und den Patch bereit. Das Prüfskript erkennt den Fix nur an der sshd-Version und meldet gepatchte Alpine-Zweige deshalb weiter als exponiert. Anmeldeversuche mit langem Passwort führen Sie nur auf eigenen oder freigegebenen Systemen aus.
Sind Router und IoT-Geräte betroffen?
Möglicherweise. OpenWrt nutzt musl, sein Standard-SSH-Server Dropbear ist aber nicht betroffen. Betroffen sein kann das optionale Paket openssh-server, das ohne PAM gebaut ist. Firmware aus Buildroot oder Yocto ist betroffen, wenn sie mit musl gebaut ist und OpenSSH ohne PAM prüft. Fragen Sie Ihre Hersteller nach dem Stand ihrer Geräte.
Was hat KI mit *sshole zu tun?
Der Entdecker hat die Lücke nach eigener Darstellung mit Agenten-Schwärmen gefunden, die rund 17.600 ungewöhnliche Anmeldeversuche gegen unterschiedlich gebaute sshd-Varianten ausführten. Das OpenSSH-Projekt berichtet seit Monaten von vielen KI-gestützten Fehlermeldungen. Laut Damien Miller finden KI-Agenten gemeldete Fehler teils binnen Stunden erneut, das Team hält lange Sperrfristen deshalb für gefährlich. Patches erscheinen schneller, und die Zeit bis zu ersten Angriffen wird kürzer.
Muss ich *sshole melden?
Die Schwachstelle allein ist nicht meldepflichtig. Eine Meldepflicht entsteht bei einem erheblichen Sicherheitsvorfall nach NIS2, bei einer Datenpanne nach DSGVO, bei einem schwerwiegenden IKT-Vorfall nach DORA oder für Hersteller bei einer aktiv ausgenutzten Schwachstelle im eigenen Produkt nach dem Cyber Resilience Act.
Wie läuft die Betroffenheitsprüfung von VamiSec ab?
Nach einem 30-minütigen Erstgespräch und Ihrer schriftlichen Freigabe prüfen wir von außen mit VamiRedteam, welche Ihrer SSH-Dienste erreichbar sind und Passwörter annehmen. Auf Wunsch prüfen wir zusätzlich von innen, lesend und ohne Änderungen, welche Server, Images und Geräte die Voraussetzungen erfüllen. Sie erhalten eine priorisierte Befundliste und einen Maßnahmenplan. Exponierte Systeme melden wir sofort.
11 · Quellen
Primärquellen und Analysen
Diese Seite fasst die Veröffentlichungen mit eigenen Worten zusammen. Verbindlich sind die Originalquellen. Wir aktualisieren die Seite, sobald sich die Lage ändert.
Wir zeigen Ihnen, welche Ihrer SSH-Dienste Passwörter annehmen, welche Systeme die Voraussetzungen für *sshole erfüllen und was Sie zuerst tun sollten.
