Kritische OpenSSH-Sicherheitslücke: Angreifer verschaffen sich Zugriff auf Linux-Server
Eine neu entdeckte Sicherheitslücke in OpenSSH sorgt derzeit für Aufsehen. Nur wenige Stunden nachdem die Schwachstelle öffentlich bekannt wurde, haben Angreifer bereits versucht, sie auszunutzen. Besonders brisant: Bei einem überwachten Testsystem gelang es ihnen, sich ohne gültiges Passwort anzumelden und Root-Rechte zu erlangen.
Die Sicherheitslücke trägt die Kennung CVE-2026-123158 und wird unter dem Namen „SSHole“ geführt. Betroffen sind bestimmte Linux-Systeme, die OpenSSH in Verbindung mit der C-Bibliothek musl und ohne PAM-Authentifizierung einsetzen.
Dazu gehört unter bestimmten Voraussetzungen auch Alpine Linux, das häufig auf Servern, in Cloud-Umgebungen und bei schlanken Linux-Installationen verwendet wird.
Ein Sicherheitsupdate ist bereits verfügbar. Administratoren sollten allerdings nicht zu lange mit der Installation warten.
Angriffe beginnen wenige Stunden nach Veröffentlichung
Die Sicherheitsforscher des Unternehmens Previdian haben nach eigenen Angaben bereits kurz nach der Veröffentlichung der Schwachstelle erste Angriffsversuche beobachtet.
Besonders auffällig ist die Geschwindigkeit.
Weniger als neun Stunden nach Bekanntwerden der Sicherheitslücke registrierten die Forscher bereits einen ersten Ausnutzungsversuch.
Insgesamt wurden zunächst acht Angriffsversuche dokumentiert, die von derselben IP-Adresse ausgingen. Diese wurde geografisch Japan zugeordnet.
Bei einem Honeypot, also einem speziell zur Beobachtung von Angriffen eingerichteten System, war der Angriff sogar erfolgreich.
Das betroffene Testsystem verwendete Alpine Linux mit einem verwundbaren OpenSSH-Server.
Den Angreifern gelang es, sich über die Schwachstelle anzumelden und Zugriff mit Root-Rechten zu erhalten.
Anschließend wurden verschiedene Befehle ausgeführt, um Informationen über das System zu sammeln.
Dabei interessierten sich die Angreifer unter anderem für die Identität des angemeldeten Benutzers, das Betriebssystem und den Rechnernamen.
Solche Abfragen sind typisch für eine erste Erkundung nach einem erfolgreichen Zugriff.
Wichtig ist allerdings die Einordnung: Die bislang dokumentierten Versuche stammen aus der Überwachung eines Honeypots. Daraus lässt sich noch nicht ableiten, dass bereits eine groß angelegte Angriffswelle gegen produktiv eingesetzte Linux-Server stattfindet.
Was steckt hinter der OpenSSH-Sicherheitslücke SSHole?
OpenSSH gehört zu den wichtigsten Werkzeugen für die sichere Fernverwaltung von Linux-Systemen.
Administratoren verwenden SSH beispielsweise, um sich auf Servern anzumelden, Konfigurationen zu ändern oder Wartungsarbeiten durchzuführen.
Normalerweise muss sich ein Benutzer dabei durch ein Passwort oder einen SSH-Schlüssel authentifizieren.
Genau an dieser Stelle setzt die neue Schwachstelle an.
Unter bestimmten Bedingungen kann OpenSSH eine fehlgeschlagene Passwortüberprüfung fälschlicherweise als erfolgreiche Anmeldung interpretieren.
Das betrifft insbesondere Benutzerkonten, für die keine nutzbare Passwortanmeldung vorgesehen ist.
Solche Konten können beispielsweise ausschließlich für den Zugriff über SSH-Schlüssel eingerichtet sein.
Eigentlich sollte eine Anmeldung mit einem Passwort bei diesen Konten grundsätzlich scheitern.
Durch einen Fehler im Zusammenspiel von OpenSSH und der musl-Bibliothek kann diese Schutzmaßnahme jedoch unterlaufen werden.
Ein einzelnes Zeichen verursacht das Problem
Technisch gesehen ist die Ursache durchaus ungewöhnlich.
Bei Linux werden Informationen über die Passwortkonfiguration von Benutzerkonten unter anderem in der Datei /etc/shadow gespeichert.
Bei bestimmten Konten befindet sich dort anstelle eines normalen Passwort-Hashes lediglich ein Sternchen (*).
Dieses Zeichen signalisiert, dass keine gewöhnliche Passwortanmeldung möglich sein soll.
Unter bestimmten Bedingungen liefert die von musl verwendete Passwortverarbeitung allerdings ebenfalls ein Sternchen zurück, wenn die Verarbeitung eines überlangen Passworts fehlschlägt.
Genau hier entsteht das Problem.
OpenSSH kann den zurückgegebenen Wert irrtümlich mit dem gespeicherten Eintrag des Benutzerkontos gleichsetzen.
Dadurch wird eine Anmeldung akzeptiert, obwohl das eingegebene Passwort nicht gültig ist.
Die Ursache hängt auch mit einer älteren Änderung an OpenSSH zusammen, die ursprünglich 2016 zur Behebung einer anderen Sicherheitslücke eingeführt wurde.
Das ist aus meiner Sicht das eigentlich Bemerkenswerte an diesem Fall: Eine frühere Sicherheitsverbesserung kann Jahre später in Verbindung mit einer bestimmten Systembibliothek zu einem völlig neuen Problem führen.
Nicht alle Linux-Systeme sind betroffen
Trotz der schwerwiegenden Auswirkungen gibt es eine wichtige Einschränkung.
Die Schwachstelle betrifft nicht grundsätzlich jede OpenSSH-Installation.
Damit ein System verwundbar ist, müssen mehrere Voraussetzungen zusammenkommen.
Dazu gehören insbesondere:
OpenSSH verwendet die musl-C-Bibliothek und führt die Passwortprüfung ohne PAM durch.
Die Passwortauthentifizierung über SSH ist aktiviert.
Mindestens ein Benutzerkonto besitzt einen gesperrten Passwortwert in Form eines Sternchens.
Ein weiteres lokales Konto verfügt über einen passenden regulären Passwort-Hash.
Besonders relevant ist diese Kombination bei bestimmten Alpine-Linux-Installationen.
Nicht betroffen sind nach den bisherigen Untersuchungen unter anderem typische glibc-basierte Linux-Systeme wie Debian, Ubuntu und Fedora, sofern sie nicht auf eine abweichende verwundbare Konfiguration umgestellt wurden.
Auch Systeme mit aktivierter PAM-Passwortprüfung oder vollständig deaktivierter SSH-Passwortanmeldung sind von diesem konkreten Angriffsweg nicht betroffen.
Ebenso ist der alternative SSH-Server Dropbear nicht durch die beschriebene Schwachstelle verwundbar.
Ein genauer Blick auf die eigene Konfiguration ist deshalb wichtiger als die bloße Frage, ob OpenSSH installiert ist.
Besonders kritisch für Alpine Linux und Cloud-Server
Alpine Linux ist wegen seiner schlanken Architektur besonders in technischen Umgebungen beliebt.
Das Betriebssystem benötigt vergleichsweise wenig Ressourcen und wird häufig für Container, virtuelle Maschinen und spezialisierte Server eingesetzt.
Bei bestimmten Alpine-Installationen sind die Voraussetzungen für die Schwachstelle gegeben.
Das betrifft insbesondere Systeme mit einem erreichbaren SSH-Dienst und aktivierter Passwortauthentifizierung.
Auch bestimmte Cloud-Images können problematisch sein.
Einige dieser Images enthalten einen Benutzer namens alpine, der normalerweise über SSH-Schlüssel verwendet wird.
Unter den entsprechenden Bedingungen kann die Sicherheitslücke jedoch auch eine Passwortanmeldung für dieses Konto ermöglichen.
Besonders gefährlich wird es, wenn der Benutzer anschließend über doas administrative Rechte erhalten kann.
Damit könnte ein Angreifer nach der Anmeldung auf das System zugreifen und anschließend Root-Rechte erlangen.
Das bedeutet allerdings nicht, dass die Sicherheitslücke grundsätzlich bei jedem betroffenen System automatisch einen direkten Root-Zugriff ermöglicht.
Welche Rechte ein Angreifer tatsächlich erhält, hängt von den jeweiligen Benutzerkonten und der Systemkonfiguration ab.
Was können Angreifer mit einem erfolgreichen Zugriff machen?
Gelingt die Ausnutzung, erhält der Angreifer zunächst die Berechtigungen des kompromittierten Benutzerkontos.
Bereits das kann erhebliche Folgen haben.
Je nach Konfiguration könnte er beispielsweise auf Anwendungsdaten, Konfigurationsdateien oder gespeicherte Zugangsinformationen zugreifen.
Besonders problematisch sind Server, auf denen Zugangsdaten für weitere Systeme hinterlegt sind.
Dazu gehören beispielsweise SSH-Schlüssel, Datenbank-Zugangsdaten oder Anmeldedaten für automatisierte Verwaltungsprozesse.
Werden solche Informationen gestohlen, könnten Angreifer unter Umständen weitere Systeme im Netzwerk kompromittieren.
Bei einem Konto mit administrativen Rechten sind die Folgen entsprechend gravierender.
Dann wäre es beispielsweise möglich, zusätzliche Benutzer einzurichten, Dienste zu verändern oder Schadsoftware dauerhaft auf dem System zu platzieren.
Genau deshalb sollte die Schwachstelle nicht als harmloser Anmeldefehler betrachtet werden.
Sicherheitsupdate für OpenSSH bereits verfügbar
Die gute Nachricht ist, dass die Entwickler schnell reagiert haben.
Mit OpenSSH 10.6p2, veröffentlicht am 5. November 2026, wurde eine Korrektur bereitgestellt.
Auch Alpine Linux hat entsprechende Sicherheitsupdates für seine Paketquellen veröffentlicht.
Dabei müssen Administratoren nicht zwangsläufig die neueste OpenSSH-Hauptversion installieren.
Für verschiedene Alpine-Versionen stehen angepasste Pakete zur Verfügung, in denen die Sicherheitskorrektur bereits enthalten ist.
Auf Alpine Linux kann die Aktualisierung beispielsweise über folgenden Befehl durchgeführt werden:
apk upgrade -U -aAnschließend muss der SSH-Dienst neu gestartet werden:
rc-service sshd restartDieser zweite Schritt ist besonders wichtig.
Die reine Installation eines aktualisierten OpenSSH-Pakets reicht nicht aus, wenn der alte SSH-Dienst weiterhin im Arbeitsspeicher läuft.
Erst nach dem Neustart verwendet der Server die aktualisierte Version.
Bei entfernten Systemen sollte man sicherstellen, dass weiterhin ein funktionierender Verwaltungszugang vorhanden ist.
Passwortanmeldung vorübergehend deaktivieren
Falls das Sicherheitsupdate nicht unmittelbar installiert werden kann, empfiehlt Alpine Linux, die Passwortauthentifizierung des SSH-Servers vorübergehend zu deaktivieren.
Dafür muss die wirksame SSH-Konfiguration den folgenden Wert enthalten:
PasswordAuthentication noAnschließend sollte die Konfiguration geprüft und der SSH-Dienst neu gestartet werden.
Die tatsächlich wirksame Einstellung lässt sich beispielsweise mit folgendem Befehl kontrollieren:
sshd -T | grep -i passwordauthenticationAls Ergebnis sollte angezeigt werden:
passwordauthentication noWichtig: Bevor die Passwortanmeldung abgeschaltet wird, muss sichergestellt sein, dass der Zugriff über SSH-Schlüssel funktioniert.
Andernfalls besteht die Gefahr, sich selbst vom Server auszusperren.
Gerade bei entfernten Cloud-Systemen ohne direkten Konsolenzugriff ist deshalb besondere Vorsicht notwendig.
Administratoren sollten auch die Protokolle überprüfen
Da bereits erfolgreiche Angriffe auf ein Testsystem beobachtet wurden, empfiehlt Alpine Linux zusätzlich eine Überprüfung der SSH-Protokolle.
Interessant sind insbesondere erfolgreiche Passwortanmeldungen bei Konten, die normalerweise überhaupt kein Passwort akzeptieren sollten.
Dazu gehören beispielsweise Benutzer, die ausschließlich für SSH-Schlüssel eingerichtet wurden.
In den Protokollen können entsprechende Ereignisse unter anderem durch Einträge mit folgendem Text auffallen:
Accepted password for
Unter Alpine Linux finden sich solche Meldungen häufig in der Datei /var/log/messages.
Administratoren sollten außerdem prüfen, ob unbekannte Benutzer angelegt, SSH-Schlüssel verändert oder ungewöhnliche administrative Aktionen durchgeführt wurden.
Wer einen unerlaubten Zugriff nicht ausschließen kann, sollte das System vorsorglich als kompromittiert betrachten.
Ein nachträglich installiertes Sicherheitsupdate beseitigt schließlich die ursprüngliche Schwachstelle, entfernt aber nicht automatisch mögliche Veränderungen durch einen bereits erfolgreichen Angreifer.
Fazit: Ein kleiner Fehler mit erheblichen Auswirkungen
Die OpenSSH-Sicherheitslücke CVE-2026-123158 zeigt ziemlich deutlich, wie gefährlich Fehler bei der Authentifizierung werden können.
Besonders bemerkenswert finde ich, dass hier keine komplizierte Angriffskette notwendig ist. Unter den passenden Voraussetzungen genügt bereits eine fehlerhafte Passwortprüfung, um den vorgesehenen Schutz eines Benutzerkontos zu umgehen.
Dass Sicherheitsforscher weniger als neun Stunden nach der Veröffentlichung erste Angriffsversuche registrierten, macht außerdem deutlich, wie schnell bekannt gewordene Schwachstellen heute aufgegriffen werden.
Allerdings sollte man die Gefahr richtig einordnen.
Nicht jeder Linux-Server mit OpenSSH ist automatisch betroffen. Entscheidend sind die verwendete Systembibliothek, die Authentifizierungskonfiguration und die vorhandenen Benutzerkonten.
Wer Alpine Linux oder andere musl-basierte Systeme mit einem erreichbaren OpenSSH-Dienst betreibt, sollte die eigene Installation dennoch umgehend überprüfen und aktualisieren.
Die Sicherheitskorrekturen stehen bereits bereit und können den beschriebenen Angriffsweg schließen.
Für mich ist dieser Fall auch eine Erinnerung daran, dass gute Serversicherheit nicht nur aus sicheren Passwörtern und SSH-Schlüsseln besteht.
Mindestens genauso wichtig sind aktuelle Software, sinnvoll eingeschränkte Berechtigungen und eine regelmäßige Kontrolle der Systemprotokolle.
Denn selbst eine vermeintlich gesperrte Passwortanmeldung bietet wenig Schutz, wenn die Software sie durch einen Fehler plötzlich doch akzeptiert.
Quellen
The Hacker News – Ravie Lakshmanan, 6. November 2026
Hackers Target OpenSSH SSHole Flaw Within Hours of Disclosure, Gain Root on Honeypot
https://thehackernews.com/2026/11/hackers-exploited-openssh-sshole-flaw.html
OpenSSH – Offizielle Release Notes, 5. November 2026
OpenSSH 10.6p2
https://www.openssh.org/releasenotes.html#10.6p2
Alpine Linux – Sicherheitshinweis, 5. November 2026
Security advisory: openssh-server password authentication bypass
https://alpinelinux.org/posts/2026-11-05-openssh-password-authentication-bypass/
Help Net Security – 6. November 2026
OpenSSH flaw exploited in the wild just hours after disclosure
https://www.helpnetsecurity.com/2026/11/06/openssh-sshole-cve-2026-123158-exploitation/
