Eine kürzlich bekannt gewordene Sicherheitslücke in OpenSSH ermöglicht es Angreifern, sich unter bestimmten Voraussetzungen ohne Passwort an verwundbaren Systemen anzumelden. Betroffen sind vor allem schlanke Linux-Systeme wie Alpine Linux, die häufig in Docker-Containern und auf Embedded-Geräten laufen.
Was genau ist passiert und wer ist betroffen?
Am 5. November 2026 wurde eine Sicherheitslücke in OpenSSH öffentlich gemacht. Diese betrifft unter anderem Systeme, die in Umgebungen mit knappen Hardware-Ressourcen laufen. Hierzu zählen Systeme, die auf Alpine Linux basieren, aber auch Distributionen wie OpenWRT (läuft unter anderem auf Routern) oder Yocto. Der gemeinsame Nenner ist, dass OpenSSH für „musl libc“ installiert ist. Mit einem CVSS-Wert von 8,1 von 10 möglichen Punkten handelt es sich um eine schwerwiegende Sicherheitslücke. Sie trägt die Bezeichnung CVE-2026-123158 und ist unter dem Namen *sshole bekannt.
Was ist musl libc?
Stark vereinfacht gesagt, handelt es sich hier um eine extraschlanke Implementierung der C-Standard-Bibliothek. Sie verfügt über einen geringeren Funktionsumfang als die „schwere“ und speicherplatzintensive glibc-Bibliothek. Sie erlaubt es, platzsparende Anwendungen für einen sehr speziellen Anwendungszweck zu bauen, der nicht den vollen Funktionsumfang der C-Umgebung benötigt. Das ist vor allem auf Geräten wichtig, auf denen Speicher- und Prozessor-Reserven knapp bemessen sind.
Wie funktioniert die Sicherheitslücke?
Die Sicherheitslücke, um die es geht, besteht eigentlich bereits seit 2016, allerdings nur in der Kombination „OpenSSH + musl libc“. Linux speichert die Passwort-Hashes der Benutzer in einer Datei (/etc/shadow). Bestimmte Konten wie etwa das Administratorkonto (unter Linux „root“ genannt) sollten von vornherein überhaupt nicht für eine Anmeldung mit Passwort über SSH freigegeben sein. Diese sind mit einem Sternchen (*) markiert.
Alle anderen Nutzerkonten, die sich anmelden dürfen, haben hinter ihrem Nutzernamen eine lange Zeichenkette stehen. Diese besteht aus einer codierten Vorgabe, welcher Hashing-Algorithmus zu nutzen ist (auf den betroffenen Systemen SHA-256 oder SHA-512), dann einem sogenannten „kryptografischen Salt“, gefolgt vom eigentlichen Passwort-Hash. Gibt ein Nutzer sein Passwort ein, wird das eingegebene Passwort nach den Vorgaben aus /etc/shadow gehasht. Ist das Ergebnis identisch mit dem Eintrag aus der Datei, geht das System davon aus, dass der Nutzer das korrekte Passwort eingegeben hat und gibt den Zugang frei.
Das Problem dabei ist: Eine musl-Systemfunktion namens crypt() erzeugt einen Fehler, wenn ein Passwort eingegeben wird, das zwischen 257 und 1024 Zeichen lang ist. Dieser Fehler wird ebenfalls in Form eines Sternchens an OpenSSH zurückgegeben. OpenSSH wiederum interpretiert das einzelne „*“ fälschlicherweise als Hash statt als Fehler und vergleicht es mit dem, was in /etc/shadow eingetragen ist – und stellt fest „Hash ist identisch – Freigabe ist damit erteilt“. Das ist nicht das, was passieren sollte; eigentlich sollte die Anmeldung abgewiesen werden.
Wer also bei der SSH-Anmeldung 257-mal „a“ als Passwort eingibt, hat auf einmal Zugang über SSH, mit den Rechten eines Accounts, der sich eigentlich gar nicht einloggen können dürfte – im ungünstigsten Fall mit Administratorrechten.
Ganz so einfach ist es nun aber doch nicht. Damit dieser Angriff gelingt, muss eine Reihe von Voraussetzungen erfüllt sein:
Linux mit musl libc (Alpine Linux, OpenWRT und andere)
OpenSSH ohne PAM (Pluggable Authentication Modules)
Passwortanmeldung ist aktiviert
Mindestens ein Benutzerkonto mit einem gültigen SHA-256- oder SHA-512-Hash sowie ein weiteres Konto, welches nur „*“ hat.
Es müssen für ein erfolgreiches Ausnutzen der Lücke ALLE diese Voraussetzungen erfüllt sein. Das ist etwa in der Standardkonfiguration bei Alpine Linux der Fall, sofern Passwörter gesetzt sind. Zudem sind mehrere Versuche erforderlich.
Wer ist NICHT betroffen?
Kurz gesagt: Alle glibc-basierten Linux-Distributionen (z. B. Debian und dessen Derivate wie Ubuntu, Linux Mint und andere), alle Nicht-Linux-Systeme (BSD, Unix, Windows) sowie Linux-Systeme, in denen Passwörter über PAM geprüft werden.
Was Linux-Anwender jetzt tun sollten
Prüfen Sie, ob Router, NAS-Laufwerke oder auch Smart-Home-Geräte einen SSH-Zugang haben.
Aktualisieren Sie die entsprechende Firmware.
Admin- oder SSH-Zugänge für Geräte und Systeme sollten niemals über das Internet erreichbar sein. Checken Sie hier gegebenenfalls Portfreigaben und -weiterleitungen in Ihrem Router.
Wer auf einem OpenWRT-Router einen OpenSSH-Server nachinstalliert hat, sollte die nachstehenden Maßnahmen ergreifen. Der vorinstallierte SSH-Server „Dropbear“ ist nicht betroffen.
Sofortmaßnahmen für Administratoren
Patch installieren; die aktuelle Version, in der die Schwachstelle behoben ist, ist die 10.6p2, beziehungsweise das jeweils aktuelle Paket der Distribution. Hinweis: Bei Alpine behalten die Pakete aus dem „stable“-Branch die ursprüngliche OpenSSH-Versionsnummer, z. B. 10.3_p1-r2, sind aber dennoch gepatcht. Die Aktualität ist hier das entscheidende Kriterium.
Neustart des Dienstes nach Installation; so ist sichergestellt, dass auch tatsächlich die aktualisierte Version des Daemons läuft und nicht die alte Version.
Falls Einspielen des aktuellen Pakets gerade nicht möglich ist:
Die Option „PasswordAuthentication no“ sowie „KbdInteractiveAuthentication no“ in der Konfigurationsdatei für sshd setzen und auch hier den Dienst neu starten. Wichtig: vorher prüfen, ob der Login per Schlüssel funktioniert – sonst sperren Sie sich möglicherweise selbst aus dem System aus!
Wo immer möglich, Anmeldungen über SSH nur per Schlüssel erlauben.
Wer Docker-Images mit betroffenen Versionen des OpenSSH-Servers einsetzt, sollte die jeweiligen Basis-Images neu bauen und ausrollen.
Werten Sie sorgfältig die /var/log/messages aus; filtern Sie mit grep nach Einträgen für sshd-Anmeldungen für Accounts ohne Anmeldeberechtigungen. Das Suchwort hier lautet „Accepted password“.
Prüfen Sie, ob neue Nutzer angelegt wurden und ob es neue Einträge unter authorized_keys gibt.
Wenn das nicht auszuschließen ist, muss die Maschine als kompromittiert betrachtet werden. Hier sind ein Neuaufsetzen und eine Änderung aller Secrets angezeigt.
Wie die Lücke aufgefallen ist
Der Entdecker dieser Sicherheitslücke, Özgün Kültekin, hat unter anderem einige KI-Agenten eingesetzt, um insgesamt 17.600 verschiedene Login-Versuche gegen verschieden kompilierte Versionen von SSH laufen zu lassen. Man spricht hier von einer üblichen und bewährten Technik namens „Fuzzing“, bei der verschiedene Inputs in eine Software eingegeben werden, um eine Reaktion hervorzurufen, welche Rückschlüsse auf potenzielle Schwachstellen zulässt.
Und in einem Fall hat eine der getesteten OpenSSH-Instanzen laut Kültekin „Ja zu Dingen gesagt, zu denen sie das nicht hätte tun dürfen“.
Ausblick
Die Zeit, die zwischen der Bekanntgabe einer Sicherheitslücke und deren aktiver Ausnutzung durch verschiedene Tätergruppen liegt, wird immer kürzer. So dauerte es in diesem Beispiel nur etwa neun Stunden. Updates und Patches zu installieren ist also etwas, das umgehend geschehen muss, und das nicht noch ein paar Wochen oder Monate warten kann. Und wer gerade keine Aktualisierung durchführen kann, sollte unbedingt die oben beschriebenen Härtungsmaßnahmen ergreifen, um unerwünschte Zugriffe auszuschließen. Zudem lohnt sich noch einmal ein genauer Blick auf das eigene Inventar: Wo sind angreifbare Systeme vorhanden? Und: Sind diese per SSH aus dem Internet erreichbar?
Ein System, das aus dem Internet nicht erreichbar ist, kann auch aus dem Internet heraus nicht angegriffen werden.
