sshole (CVE-2026-123158): Die OpenSSH-Schwachstelle, die Alpine Linux trifft und wie man sie behebt

Von Eoin Villarin, 2026-11-07

Eine OpenSSH-Schwachstelle namens sshole ermöglicht Angreifern die Anmeldung an passwortlosen Konten auf Alpine Linux und anderen musl-basierten Systemen und wird bereits ausgenutzt. Wer ist betroffen, wie kann ich meine Server überprüfen und wie kann ich es beheben.

Bin ich von der sshole OpenSSH-Schwachstelle betroffen?

Sie sind gefährdet, wenn ein Server OpenSSH älter als 10.6p2 auf einem musl-basierten System wie Alpine Linux ohne PAM ausführt, SSH-Passwortanmeldungen zulässt und ein Konto hat, dessen Passwortfeld nur ein Stern neben einem anderen Konto mit einem echten Passwort-Hash ist. Debian, Ubuntu, Fedora und Konfigurationen, die PAM verwenden, sind nicht betroffen.

Zentrale Erkenntnisse

CVE-2026-123158, genannt sshole, ermöglicht Angreifern die Anmeldung an passwortlosen Konten auf musl-basierten Linux-Systemen durch Senden eines übergroßen Passworts.
Alpine Linuxs standardmäßiges openssh-server-Paket ist betroffen, während glibc-Systeme wie Ubuntu und Setups, die PAM verwenden, nicht betroffen sind.
Angreifer haben es weniger als neun Stunden nach seiner Veröffentlichung ausgenutzt und haben auf einem Honeypot root-Rechte erlangt.
Die Korrektur ist OpenSSH 10.6p2 oder Alpiners gepatchtes Paket für Ihren Zweig, gefolgt von einem sshd-Neustart.
Wenn Sie noch nicht aktualisieren können, setzen Sie PasswordAuthentication no und verwenden Sie SSH-Schlüssel.

Eine neu entdeckte OpenSSH-Schwachstelle namens sshole, die als CVE-2026-123158 verfolgt wird, ermöglicht Angreifern die Anmeldung an bestimmten Linux-Konten, die nicht dazu bestimmt sind, Passwörter zu akzeptieren. Sie betrifft OpenSSH auf musl-basierten Systemen wie Alpine Linux, wurde am 5. November 2026 behoben und Angreifer begannen, sie weniger als neun Stunden nach ihrer Veröffentlichung auszunutzen. Wenn Sie Alpine-Server, Alpine-basierte Docker-Images mit SSH oder kleine Geräte auf OpenWrt betreiben, überprüfen Sie sie heute.

Was ist die sshole OpenSSH-Schwachstelle?

Auf musl-basierten Systemen gibt die C-Bibliotheksfunktion crypt() einen einzelnen Stern (*) zurück, wenn sie ein Passwort nicht hash kann, z.B. wenn das Passwort länger als seine 256-Byte-Grenze ist. Viele Linux-Systeme verwenden auch einen einzelnen * im Passwortfeld, um zu bedeuten "dieses Konto hat kein Passwort". OpenSSH verglich die beiden, sah *, und behandelte es als Übereinstimmung. Das Senden eines übergroßen Passworts genügte, um sich bei einem konto ohne Passwort anzumelden.

Das Verhalten geht auf eine Änderung im Jahr 2016 in OpenSSHs Passwortbehandlung zurück. Sicherheitsforscher Özgün Kültekin fand es mithilfe von KI-Agenten, die etwa 17.600 Authentifizierungstests durchführten. Der CVE trägt einen CVSS 3.1-Score von 8.1, der als Hoch bewertet wird, und die Korrektur wurde in OpenSSH 10.6p2 ausgeliefert.

Bin ich betroffen?

Ein Server ist gefährdet, wenn alle folgenden Bedingungen erfüllt sind:

Es läuft OpenSSH älter als 10.6p2 auf einem musl-basierten System, wie z.B. Alpine Linux, OpenWrt, Buildroot oder Yocto.
sshd verwendet PAM nicht. Dies ist die Standardeinstellung für Alpin's openssh-server-Paket.
SSH-Passwortanmeldungen sind aktiviert, was der OpenSSH-Standard ist.
Zumindest ein Konto hat nur * in seinem Passwortfeld, wie ein benutzerdefinierter Schlüssel, neben einem anderen Konto mit einem echten Passwort-Hash.

Alpines offizielle AWS- und Azure-Cloud-Images von 3.18.11 bis 3.24.3 sind ein ernster Fall: Sie enthalten einen standardmäßigen Alpine-Benutzer ohne Passwort und passwortloses doas, was bedeutet, dass eine erfolgreiche Anmeldung zu root werden kann.

Nicht betroffen: glibc-basierte Systeme wie Debian, Ubuntu und Fedora, Konfigurationen, die Passwörter über PAM, Dropbear und OpenBSD überprüfen. Konten mit einem echten Passwort-Hash können auf diese Weise nicht umgangen werden.

So überprüfen Sie Ihre Server

Führen Sie diese als root auf jedem Alpine-Server oder -Container aus, der sshd ausführt:

Überprüfen Sie die SSH-Einstellungen: sshd -T | grep -i -E 'passwordauthentication|usepam'. Wenn die Passwortauthentifizierung deaktiviert oder PAM aktiviert ist, kann diese Schwachstelle nicht ausgenutzt werden.
Überprüfen Sie das installierte Paket: apk list --installed | grep openssh, und vergleichen Sie es mit den untenstehenden korrigierten Versionen.
Liste Konten ohne Passwort: awk -F: '$2=="*" {print $1}' /etc/shadow.
Suchen Sie nach Anmeldungen bei diesen Konten: grep "Accepted password" /var/log/messages. Eine Passworteingabe in ein Konto mit * im Passwortfeld bedeutet, dass der Server wahrscheinlich angegriffen wurde.

So beheben Sie CVE-2026-123158 unter Alpine Linux

Alpine hat für jeden Zweig von 3.16 bis edge an demselben Tag wie die Offenlegung gepatchte Pakete ausgeliefert. Aktualisieren und starten Sie sshd neu, da die Installation des Updates den laufenden Prozess nicht neu startet:

apk upgrade -U -a und dann rc-service sshd restart

Alpine-Zweig	Korrigierte OpenSSH-Version
edge	10.6_p2-r0
3.24	10.3_p1-r2
3.23	10.2_p1-r1
3.22	10.0_p1-r11
3.21	9.9_p2-r1
3.20	9.7_p1-r6
3.19	9.6_p1-r3
3.18	9.3_p2-r4
3.17	9.1_p1-r7
3.16	9.0_p1-r6

Für Docker müssen Sie jedes Image, das OpenSSH enthält, aus einem frischen Basis-Image neu erstellen und neu bereitstellen. Beachten Sie, dass einige SSH-Images auf Docker Hub, wie z.B. linuxserver's openssh-server, standardmäßig die Passwortanmeldung ausschalten, aber exponiert werden, wenn PASSWORD_ACCESS=true gesetzt wird.

Ältere Alpine-Versionen als 3.16 erhalten kein fixes Paket. Upgrade Sie auf eine unterstützte Version oder verwenden Sie die untenstehende Problemumgehung.

Schnelllösung: SSH-Passwortanmeldungen ausschalten

Wenn Sie nicht sofort aktualisieren können, setzen Sie PasswordAuthentication no in /etc/ssh/sshd_config, starten Sie sshd neu und führen Sie den sshd -T-Test erneut aus. Stellen Sie sicher, dass Ihre SSH-Schlüsselanmeldung funktioniert, bevor Sie dies tun, sonst können Sie sich selbst aussperren. Schlüssel-only SSH ist jedoch eine gute Standard-Einstellung für jeden Server.

Was tun, wenn Sie denken, dass Sie getroffen wurden

Überprüfen Sie die doas-Nutzung, kürzlich erstellte Benutzer und jede authorized_keys-Datei.
Überprüfen Sie auf unbekannte Prozesse, cron-Jobs und ausgehende Verbindungen.
Wenn Sie einen Kompromiss nicht ausschließen können, behandeln Sie den Server als kompromittiert: erstellen Sie ihn aus einem sauberen Image neu und drehen Sie jedes Passwort, jeden Schlüssel und jedes Token, das er hielt.
Downloaden Sie keine Proof-of-Concept-Exploits von GitHub, um Ihre Server zu testen. Forscher warnen, dass einige nicht verifiziert sind und Malware enthalten können.

Das Patchen von Servern ist ein wichtiger Teil der Website-Wartung Ich mache das für Kunden. Wenn Sie Hilfe benötigen, um Ihre Hosting-, Docker-Setup- oder SSH-Konfiguration zu überprüfen, Sich in Kontakt setzen.

Häufig gestellte Fragen

Ist Ubuntu oder Debian von sshole betroffen?

Nein. Debian, Ubuntu, Fedora und andere glibc-basierte Systeme sind nicht betroffen, ebenso wenig wie Konfigurationen, die PAM für Passwortprüfungen verwenden.

Schützt mich eine schlüsselbasierte SSH?

Ja. Wenn PasswordAuthentication auf nein gesetzt ist, akzeptiert der Server keine Passwörter, sodass die Schwachstelle nicht ausgenutzt werden kann.

Wird CVE-2026-123158 ausgenutzt?

Ja. Das Threat-Intelligence-Unternehmen Previdian sah den ersten Versuch weniger als neun Stunden nach der Veröffentlichung der CVE, und ein Angreifer erlangte Root-Rechte auf einem seiner Honeypots, auf dem Alpine Linux lief.

Welche OpenSSH-Version behebt es?

OpenSSH 10.6p2. Installieren Sie auf Alpine das gepatchte openssh-Paket für Ihren Zweig und starten Sie sshd neu.

Sind Docker-Container betroffen?

Container, die auf Alpine basieren und sshd mit aktivierten Passwortanmeldungen ausführen, können betroffen sein. Bauen Sie sie aus einem aktualisierten Basisimage neu und setzen Sie sie erneut ein.

Muss ich nach dem Update neu starten?

Ja. Der laufende sshd behält den anfälligen Code im Speicher, bis Sie den Dienst neu starten.