OpenSSH Sicherheitslücke SSHole: Login ohne Passwort auf Alpine

Hinweis: Dieser Beitrag wurde mit KI-Unterstützung erstellt und automatisiert veröffentlicht.

Eine OpenSSH Sicherheitslücke mit dem Spitznamen „SSHole“ erlaubt auf bestimmten Linux-Systemen eine Anmeldung ohne gültiges Passwort. Das OpenSSH-Projekt hat am 5. November 2026 außer der Reihe die Version 10.6p2 veröffentlicht und spricht dort selbst von einem „critical security workaround“. Am Tag darauf meldeten erste Beobachter Angriffsversuche. Wer SSH auf einem musl-basierten System betreibt, sollte heute handeln.

Was bei der OpenSSH Sicherheitslücke technisch passiert

Die Lücke trägt die Nummer CVE-2026-123158 und wird im NVD-Eintrag mit CVSS 3.1 8.1 (hoch) geführt – vergeben vom CNA, die NVD-Analyse selbst steht noch aus. Der Vektor stuft die Angriffskomplexität als hoch ein, weil die Kontenkonstellation stimmen muss; sitzt sie, ist der Angriff selbst trivial. Betroffen ist sshd vor Portable OpenSSH 10.6p2 auf Linux, wenn die musl-libc verwendet wird und die Passwortprüfung ohne PAM läuft. Alpine Linux ist genau so gebaut und darum das prominenteste Beispiel.

Der Mechanismus ist bemerkenswert banal. Ohne PAM prüft sshd ein Passwort, indem es die Eingabe per crypt() hasht und das Ergebnis mit dem gespeicherten Feld vergleicht. Die musl-Implementierung von crypt() gibt bei Eingaben über 256 Byte als Fehlersignal die Zeichenkette * zurück. Und genau dieses * steht im Shadow-Eintrag jedes Kontos, das bewusst kein Passwort hat – etwa bei reinen Schlüssel-Logins. Fehlersignal und gespeicherter Wert sind identisch, die Prüfung gilt als erfolgreich. Ein Passwort zwischen 257 und 1.024 Byte genügt, Wiederholungen braucht es nicht. Die Wurzel liegt laut OpenSSH außerhalb von sshd, ausnutzbar war sie aber über sshd – und sie geht auf einen Patch von 2016 gegen eine Benutzernamen-Enumeration (CVE-2016-6210) zurück.

AD-Checkliste

Dein AD härten: 12 Sofortmaßnahmen

Das PDF mit Bordmitteln, PowerShell-Prüfbefehlen und 30-Tage-Reihenfolge – per Mail, sobald du deine Anmeldung zum Tech-&-Tacheles-Newsletter bestätigst.

E-Mail-Adresse *

Mit der Anmeldung erhältst du die AD-Checkliste als PDF und danach den Tech-&-Tacheles-Newsletter mit Einordnungen zu Security, KI und Crypto sowie gelegentlichen Hinweisen auf meine Bücher und Produktempfehlungen (auch Affiliate-Links) – eingetragen bist du erst nach Klick auf den Bestätigungslink in der E-Mail (Double-Opt-in). Ich werte aus, ob du den Newsletter öffnest und Links anklickst, um ihn zu verbessern. Abmeldung jederzeit über den Link in jeder E-Mail, Details in der Datenschutzerklärung.

Wer betroffen ist – und wer nicht

Alpine nennt vier Bedingungen, die gleichzeitig erfüllt sein müssen: ein openssh-server ohne PAM (oder mit UsePAM no), PasswordAuthentication yes – der Standard – und ein Konto, dessen Passwortfeld * ist. Zusätzlich muss mindestens ein lokales Konto einen echten $5$– oder $6$-Hash besitzen, weil sshd sich von dort das Salt leiht. Betroffen sind laut Advisory alle geprüften Alpine-Zweige von 3.16 bis 3.24 und edge.

• Nicht betroffen: Container, in denen gar kein sshd läuft; Systeme mit PasswordAuthentication no; openssh-server-pam mit UsePAM yes; glibc-Distributionen; gesperrte Konten mit ! im Shadow-Feld.
• Besonders heikel: die offiziellen tiny-cloud-Images von 3.18.11 bis 3.24.3. Dort hat der Benutzer alpine ein *-Feld und passwortloses doas – aus dem Login wird also schnell Root. Beim ersten Boot sind sie noch sicher; ausnutzbar werden sie, sobald irgendein $6$-Hash auf der Maschine existiert, etwa weil ein Admin ein Konsolen-Passwort setzt.

Die Angriffsvoraussetzung ist niedrig, aber nicht null: Es braucht einen erreichbaren SSH-Port und den Namen eines passwortlosen Kontos. Dass alpine oder deploy dazu gut geraten sind, muss man nicht erklären. root trägt zwar seit etwa Alpine 3.16 ein *-Feld, ist aber durch die OpenSSH-Voreinstellung PermitRootLogin prohibit-password direkt nicht erreichbar – gefährlich wird es über ein anderes Konto, das per doas Root werden kann.

Was das für dich bedeutet

Aus CISO-Sicht ist das kein spektakulärer Exploit, sondern ein Inventarproblem. Alpine steckt in sehr vielen Umgebungen, ohne dass es im Asset-Verzeichnis steht: als Basis-Image in CI-Runnern, als schlanke VM für einen Reverse Proxy, als Appliance-Unterbau, in Homelab-Hypervisoren. Die Frage lautet darum nicht „läuft bei uns Alpine?“, sondern „wo läuft bei uns ein sshd, von dem wir nichts wissen?“. In 25 Jahren IT war die Antwort darauf praktisch nie „nirgends“.

Zweitens zeigt der Fall, warum Passwort-Authentifizierung am SSH-Port eine Altlast ist. Hätten die betroffenen Systeme PasswordAuthentication no gesetzt, wäre die Lücke für sie nie relevant geworden – und zwar ohne Patch. Dieselbe Logik galt zuletzt beim SonicWall-MFA-Bypass CVE-2026-19868: Wer sich auf einen einzigen Authentifizierungspfad verlässt, verliert alles, wenn dieser Pfad bricht. Schlüssel plus ein zweiter Faktor für die Konten, die wirklich Rechte haben, sind kein Luxus. Wer hier aufräumen will, findet in meinem Ratgeber zu Hardware-Security-Keys mit FIDO2 die Geräte, die dafür in Frage kommen.

Drittens: Panik ist nicht angebracht. Es gibt bisher einzelne beobachtete Angriffsversuche – eine Handvoll Quell-IPs, keine Massenwelle; in den KEV-Katalog der CISA hat es die Lücke nicht geschafft. Harmlos ist das aber nicht: Der Threat-Intelligence-Anbieter Previdian bestätigt einen erfolgreichen Root-Zugriff auf einem Alpine-Honeypot, und der erste Versuch kam weniger als neun Stunden nach der CVE-Veröffentlichung. Konten mit echtem Passwort-Hash sind nicht umgehbar. Aber die Lücke ist trivial auszunutzen, öffentlich dokumentiert und erfordert keine Vorbereitung – das reicht für „heute, nicht nächsten Wartungstag“.

Praxis: drei Schritte für heute

• Patchen und neu starten. apk upgrade -U -a, danach zwingend rc-service sshd restart – ein Paket-Update tauscht den laufenden Daemon nicht aus. Fixiert sind unter anderem Alpine 3.21.10, 3.22.8, 3.23.8 und 3.24.4; für die alten Zweige bis 3.16 gibt es gepatchte Pakete.
• Passwort-Login abschalten, wenn du nicht sofort patchen kannst. PasswordAuthentication no in die sshd-Konfiguration, dann sshd -t && rc-service sshd restart und mit sshd -T | grep -i passwordauthentication gegenprüfen. Vorher den Schlüssel-Login testen und die bestehende Sitzung offen halten – sonst sperrst du dich selbst aus.
• Nachsehen, ob schon jemand da war. In /var/log/messages nach Accepted password for in Verbindung mit Konten suchen, die gar kein Passwort haben. Dazu doas-Nutzung, neu angelegte Benutzer und authorized_keys prüfen. Alpine ist hier eindeutig: Lässt sich ein Login nicht ausschließen, gilt die Maschine als kompromittiert.

Und für danach eine Hausaufgabe: einmal durch alle Images und VM-Vorlagen gehen und prüfen, welche davon einen sshd mit Passwort-Login mitbringen. Diese OpenSSH Sicherheitslücke ist in ein paar Tagen gepatcht. Das Inventarproblem bleibt.

Quellen

• OpenSSH: Release Notes Portable OpenSSH 10.6p2 (05.11.2026)
• Alpine Linux: Security advisory – openssh-server password authentication bypass (05.11.2026)
• NVD: CVE-2026-123158
• The Hacker News: Hackers Target OpenSSH SSHole Flaw Within Hours of Disclosure, Gain Root on Honeypot (06.11.2026)
• Help Net Security: OpenSSH „SSHole“ – Ausnutzung und Hintergrund (06.11.2026)