Am 05.11.2026 hat das OpenSSH-Projekt die Version 10.6p2 veröffentlicht und damit die Lücke CVE-2026-123158 geschlossen, die unter dem Namen „sshole“ bekannt ist. Auf bestimmten musl-basierten Linux-Systemen ohne PAM kann sich ein entfernter Angreifer mit einem beliebigen, überlangen Passwort anmelden, und zwar bei Accounts, die eigentlich gar kein Passwort haben. Betroffen sind vor allem Alpine Linux und ähnliche Systeme in Containern, CI-Runnern, Edge-Geräten und Routern; ein Proof-of-Concept ist bereits öffentlich. Dieser Beitrag zeigt, wann die Lücke greift, wie Sie Ihre Systeme prüfen und welche Schritte wir aus der Praxis empfehlen.
Was hinter „sshole“ steckt
Die Schwachstelle wurde von Özgün Kültekin (Wakefield Research) entdeckt und benannt. MITRE bewertet sie mit CVSS 8.1 (hoch). Das deutsche Bundesamt für Sicherheit in der Informationstechnik (BSI) hat am 06.11.2026 eine IT-Sicherheitsmitteilung in Version 1.0 mit der Kritikalität „2 hoch“ veröffentlicht.
Vereinfacht passiert Folgendes: sshd prüft Passwörter auf diesen Systemen über die Funktion crypt() der musl libc. Bei überlangen Passwörtern liefert musl einen Fehlerwert zurück. Unter den richtigen Bedingungen wird dieser Fehlerwert so interpretiert, dass die Authentifizierung als erfolgreich gilt.
Die Wirkung ist deutlich: Ein Angreifer, der den SSH-Port erreicht und einen gültigen Account-Namen kennt, kann sich mit JEDEM Passwort der Länge 257 bis 1024 Byte anmelden, sofern das Passwort-Feld dieses Accounts in /etc/shadow „*“ lautet. Das betrifft typischerweise Key-only-Accounts. Dafür genügt ein einziger Verbindungsversuch. Der Angreifer muss also weder raten noch ein Timing ausnutzen.
Eine Klarstellung, die in Gesprächen immer wieder auftaucht: Der Bug liegt nach Einschätzung des OpenSSH-Teams nicht in sshd selbst. Er entsteht im Zusammenspiel von OpenSSH und musl libc. Behoben wird er trotzdem über das OpenSSH-Update.
Wann die Lücke tatsächlich ausnutzbar ist
Für die Bewertung Ihrer Umgebung ist wichtig: Die Lücke greift nur, wenn alle der folgenden Voraussetzungen gleichzeitig erfüllt sind.
OpenSSH läuft auf Linux mit musl libc, und sshd läuft ohne PAM.
Die Passwort-Authentifizierung für SSH ist aktiviert.
Zum Beispiel root auf Alpine seit 3.16, Key-only-User, der alpine-User in den offiziellen tiny-cloud-Images oder Verzeichnis-User über musl-nscd.
Mindestens ein lokaler Account hat einen Passwort-Hash vom Typ SHA-256 ($5$) oder SHA-512 ($6$).
Der Angreifer erreicht den SSH-Port und kennt einen gültigen Account-Namen.
Abbildung: Fünf Bedingungen, die gemeinsam erfüllt sein müssen, damit CVE-2026-123158 („sshole“) ausnutzbar ist (UND-Logik).
Diese UND-Logik ist eine gute Nachricht für die Priorisierung, aber kein Grund zur Entwarnung. Gerade bei Alpine sind Punkt 1 und 3 im Standardzustand bereits erfüllt. Ob ein Passwort-Login für root überhaupt zugelassen ist, steuert zusätzlich die Option PermitRootLogin. Prüfen Sie diesen Wert, verlassen Sie sich aber nicht darauf: Auch andere Key-only-Accounts kommen als Ziel infrage.
Welche Plattformen betroffen sind
Alpine Linux 3.16 bis 3.24 sowie edge
Ja, laut Alpine Security Advisory vom 05.11.2026
Das Standard-Paket openssh-server wird ohne PAM gebaut. Auch openssh-server-pam mit „UsePAM no“ ist betroffen. Paket aktualisieren, sshd neu starten.
OpenWrt
Nur, wenn OpenSSH statt des Standards Dropbear läuft
Update-Stand beim jeweiligen Projekt bzw. Hersteller prüfen
Buildroot, Yocto
Möglich, abhängig vom Build
Eigene Images auf OpenSSH 10.6p2 heben
Void Linux (musl)
Möglich, abhängig von der Konfiguration
Update-Stand der Distribution prüfen
Container auf musl-Basis
Nur, wenn im Container ein sshd läuft
Images neu bauen, nicht nur laufende Container patchen
Debian, RHEL, Ubuntu und andere glibc-Systeme
Nein
Die Lücke setzt musl libc voraus
In der Praxis finden wir solche Systeme selten im zentralen Serverbestand. Sie stecken eher in CI-Runnern, in Debug-Containern mit eingebautem sshd, in Appliances und auf Edge-Geräten, die irgendwann jemand aufgesetzt hat und die seitdem einfach laufen.
So prüfen Sie Ihre Systeme
Die folgenden Befehle laufen auf Alpine und anderen musl-Systemen mit Root-Rechten. Zuerst klären Sie die Plattform und die effektive sshd-Konfiguration:
# Läuft das System mit musl libc?
ls /lib/ld-musl-* 2>/dev/null
# Effektive sshd-Konfiguration auslesen
sshd -T | grep -Ei '^(usepam|passwordauthentication|permitrootlogin) 'Lautet die Ausgabe passwordauthentication yes und steht usepam no da (oder fehlt die usepam-Zeile, weil sshd in der Regel dann ohne PAM gebaut ist), sollten Sie weiterprüfen. Danach sehen Sie sich die Passwort-Felder an:
# Accounts mit Passwort-Feld "*"
awk -F: '$2 == "*" {print $1}' /etc/shadow
# Accounts mit SHA-256- oder SHA-512-Hash
awk -F: '$2 ~ /^\$[56]\$/ {print $1}' /etc/shadowLiefern beide Abfragen Treffer, ist das System bei aktivem Passwort-Login und erreichbarem SSH-Port als gefährdet einzustufen. Zum Schluss klären Sie den Paketstand:
apk info -v 2>/dev/null | grep opensshEin zusätzlicher Blick in die Logs lohnt sich. Key-only-Accounts sollten nie per Passwort angemeldet werden. Je nach Logging-Setup finden Sie Anmeldungen zum Beispiel so:
grep "Accepted password" /var/log/messagesEin Treffer für root oder einen anderen Key-only-Account ist ein Anlass für eine genauere Untersuchung.
Sofortmaßnahme und Update
Der Fix ist OpenSSH 10.6p2. Alpine empfiehlt, das Paket openssh-server zu aktualisieren und sshd neu zu starten, damit der laufende Daemon tatsächlich ersetzt wird:
apk update
apk add --upgrade openssh-server # bzw. openssh-server-pam
rc-service sshd restartKönnen Sie nicht sofort aktualisieren, deaktivieren Sie als Sofortmaßnahme den Passwort-Login. Tragen Sie dazu in /etc/ssh/sshd_config vor allen Match-Blöcken Folgendes ein:
PasswordAuthentication noAnschließend prüfen Sie die Syntax, kontrollieren den effektiven Wert und starten sshd neu:
sshd -t && sshd -T | grep -i '^passwordauthentication'
rc-service sshd restartUnser Rat: Stellen Sie vorher sicher, dass der Key-Login für Ihre Admin-Accounts funktioniert, und lassen Sie eine bestehende Sitzung offen, bis die neue Anmeldung klappt. SSH-Key-Login bleibt von der Lücke unberührt.
Die Stolpersteine, die wir in der Praxis sehen
Ein apk upgrade allein schützt nicht, solange der alte sshd-Prozess weiterläuft. Deshalb betont Alpine den Neustart ausdrücklich. Bei uns gehört zur Patch-Verifikation immer die Kontrolle, dass der laufende Dienst die neue Version verwendet.
Ein Update im laufenden Container ist mit dem nächsten Neustart wieder weg. Bauen Sie die Images mit aktuellem Basis-Image neu (zum Beispiel mit docker build --pull) und rollen Sie sie aus. In Kubernetes heißt das: neues Image-Tag, kontrollierter Rollout.
Router mit nachinstalliertem OpenSSH, selbst gebaute Yocto- oder Buildroot-Images und alte CI-Runner tauchen in keiner CMDB auf. Genau dort ist Passwort-Login oft noch aktiv, „weil es beim Einrichten praktisch war“.
Viele Betreiber gehen davon aus, dass ein Account ohne gesetztes Passwort per Passwort gar nicht erreichbar ist. Bei dieser Lücke ist genau das der Angriffsweg.
Was die Lücke über den Patch-Alltag verrät
Das OpenSSH-Team schreibt in der Release-Ankündigung, dass es zuletzt eine große Zahl an Security-Bug-Reports erhalten hat, viele davon von KI-Modellen oder mit KI-Hilfe gefunden. Das Projekt will deshalb künftig häufiger Releases veröffentlichen, um Fixes schneller zu liefern, statt sie bis zum nächsten geplanten Release zu bündeln. Sinngemäß begründet das Team das so: Wer solche Bugs nicht an Open-Source-Projekte meldet, sondern selbst ausnutzen will, findet sie vermutlich ebenfalls.
Für Betreiber heißt das: Kürzere Abstände zwischen Sicherheits-Releases werden zum Normalfall. Gefragt ist ein Patch-Prozess, der kleine, häufige Updates verlässlich ausrollt, deren Wirksamkeit prüft und betroffene Teams zeitnah informiert. Ein jährlicher Wartungstermin reicht dafür nicht aus.
Zum aktuellen Stand: Zum Zeitpunkt der Veröffentlichung sind keine öffentlich bestätigten Angriffe bekannt. Da ein Proof-of-Concept öffentlich verfügbar ist, sollten Sie das nicht als Grund zum Abwarten sehen.
Checkliste für Ihren SSH-Betrieb
Wissen Sie, auf welchen Ihrer Systeme, Container und Geräte musl libc und OpenSSH laufen?
Ist auf diesen Systemen die Passwort-Authentifizierung für SSH deaktiviert?
Haben Sie geprüft, welche Accounts in /etc/shadow das Passwort-Feld „*“ haben?
Sind alle betroffenen Alpine-Systeme auf dem gepatchten openssh-server-Paket, und wurde sshd danach neu gestartet?
Sind Ihre Container-Images mit aktuellem Basis-Image neu gebaut und ausgerollt?
Haben Sie OpenWrt-Geräte, Edge-Hardware und eigene Buildroot- oder Yocto-Images in Ihre Prüfung einbezogen?
Ist der SSH-Port nur aus den Netzen erreichbar, die ihn wirklich brauchen?
Haben Sie die Logs auf Passwort-Anmeldungen bei Key-only-Accounts durchsucht?
Häufige Fragen
Nein. Die Lücke setzt musl libc voraus. Systeme mit glibc, etwa Debian, RHEL oder Ubuntu, sind nicht betroffen. Ein Update auf aktuelle OpenSSH-Pakete ist dort trotzdem Teil der normalen Pflege.
Nein. Die Lücke betrifft ausschließlich die Passwort-Prüfung. SSH-Key-Login bleibt davon unberührt, und genau deshalb ist das Abschalten des Passwort-Logins eine wirksame Sofortmaßnahme.
Als Sofortmaßnahme ja, sofern Sie sshd danach neu starten und den effektiven Wert mit sshd -T kontrollieren. Das Update auf das gepatchte Paket sollten Sie dennoch einplanen, damit eine spätere Konfigurationsänderung die Lücke nicht wieder öffnet.
Zum Zeitpunkt der Veröffentlichung sind keine öffentlich bestätigten Angriffe bekannt. Ein Proof-of-Concept ist allerdings öffentlich verfügbar, daher rechnen wir mit Scans auf erreichbare SSH-Ports.
Nein, ohne laufenden SSH-Server gibt es keinen Angriffsweg über diese Lücke. Prüfen Sie aber, ob Debug- oder Build-Images doch einen sshd enthalten.
Fazit
„sshole“ trifft genau die Systeme, die im Alltag am wenigsten Aufmerksamkeit bekommen: schlanke Alpine-Container, CI-Runner und Geräte am Rand des Netzes. Die Voraussetzungen sind eng, aber auf Alpine im Standardzustand schnell erfüllt. Unser Rat: Schalten Sie den Passwort-Login für SSH heute ab, aktualisieren Sie openssh-server, starten Sie sshd neu und prüfen Sie danach, ob der Patch wirklich läuft.
Stand der Informationen: November 2026. Dieser Beitrag basiert auf der Release-Ankündigung von OpenSSH 10.6p2 (05.11.2026), dem Alpine Security Advisory (05.11.2026) und der IT-Sicherheitsmitteilung des BSI (06.11.2026). Bitte prüfen Sie für Ihre Plattform den jeweils aktuellen Stand beim Hersteller.
Klingt spannend? Reden wir darüber
ONTEC betreibt für Kunden Linux-Server, Container und Kubernetes-Umgebungen mit 24/7-Monitoring. Bei Lücken wie dieser beginnen wir mit der Inventarisierung: Wo laufen musl-Systeme, wo ist OpenSSH aktiv, wo ist Passwort-Login erlaubt? Anschließend setzen wir Sofortmaßnahmen um und rollen die Patches kontrolliert aus.
Im Patch-Management ist die Verifikation für uns genauso wichtig wie das Update selbst: Wir prüfen, ob die neuen Pakete installiert sind, die Dienste neu gestartet wurden und die Container-Images neu gebaut sind. Über Patch-Broadcasts informieren wir die betroffenen Teams zeitnah. Wenn Sie wissen möchten, ob Ihre Umgebung betroffen ist, oder Ihren SSH-Betrieb dauerhaft absichern wollen, sprechen Sie uns an.
Hannes Gruber
ONTEC AG
Kundenorientierung bedeutet für mich sich in die Lage des Kunden versetzen zu können. Genaues Zuhören, verstehen und ein fachlich top aufgestelltes Team sind hierbei entscheidend, um den Kunden die optimale Lösung anzubieten.