SSHole CVE-2026-123158: Erste Angriffsversuche auf OpenSSH-Lücke unter Alpine
Die OpenSSH-Lücke SSHole auf Alpine Linux trägt jetzt die Kennung CVE-2026-123158 mit CVSS 8.1. Previdian hat am 6. November 2026 die ersten 14 Angriffsversuche registriert. Admins sollten das Update einspielen, sshd neu starten und die Logs auf fremde Anmeldungen prüfen.
Die Passwort-Umgehung in OpenSSH auf Alpine Linux hat inzwischen die Kennung CVE-2026-123158 und eine CVSS-Bewertung von 8.1. Der Sicherheitsdienst Previdian meldet erste Angriffsversuche: Seine Sensoren haben am 6. November 2026 insgesamt 14 Versuche von 9 IP-Adressen aus 8 Ländern registriert. Die erste Beobachtung lag laut Previdian rund acht Stunden nach der Veröffentlichung der CVE. Öffentliche Proof-of-Concepts und Scanner gibt es seit dem 5. November auf GitHub.
Betroffen sind Linux-Systeme, auf denen sshd mit der C-Bibliothek musl und ohne PAM läuft, vor allem Alpine Linux in der Standardkonfiguration. Debian, Ubuntu und andere glibc-Systeme sind nicht betroffen. Wer Alpine-Server mit erreichbarem SSH-Port betreibt und das Update vom 5. November noch nicht eingespielt hat, sollte das sofort nachholen und danach die Logs prüfen.
Was ist passiert?
Am 5. November hatte das OpenSSH-Projekt die Version 10.6p2 veröffentlicht, Alpine stellte am selben Tag korrigierte Pakete bereit. S-EDV hat darüber berichtet, damals noch ohne CVE-Nummer. Inzwischen führt das CVE-Programm die Lücke als CVE-2026-123158. Laut Beschreibung akzeptiert sshd vor 10.6p2 unter musl ohne PAM für bestimmte Konten jedes Passwort mit einer Länge zwischen 256 und 1024 Zeichen.
Previdian stuft die Ausnutzungsversuche als bestätigt ein, betont aber selbst, dass die Sensordaten nicht zeigen, ob ein Ziel verwundbar war oder ein Versuch gelang. Laut The Hacker News hat Previdian auf einem Honeypot mit Alpine Linux einen erfolgreichen root-Zugriff festgestellt. Previdian-Gründer Ryan Dewhurst sagte dem Magazin, der Angreifer habe Befehle wie id, uname und hostname ausgeführt. Der root-Zugriff steht nicht auf der Previdian-Seite selbst. Im KEV-Katalog der CISA steht die Lücke bisher nicht.
Wer ist betroffen?
Laut Alpine müssen alle Bedingungen zutreffen: Das Paket openssh-server ohne PAM ist installiert oder openssh-server-pam läuft mit UsePAM no. PasswordAuthentication steht auf yes, was der Standard ist. Es gibt ein Konto, dessen Passwortfeld nur ein Sternchen enthält, und mindestens ein weiteres Konto mit einem Passwort-Hash. Konten mit Sternchen sind etwa reine Schlüsselkonten und root, das seit etwa Alpine 3.16 so ausgeliefert wird. root schützt die Standardeinstellung PermitRootLogin prohibit-password, ein anderes Konto mit doas-Rechten öffnet aber trotzdem den Weg zu root.
Besonders gefährdet sind die offiziellen tiny-cloud-Abbilder von 3.18.11 bis 3.24.3 mit dem Nutzer alpine und doas ohne Passwort, sobald auf der Maschine ein Passwort gesetzt wird. Nicht betroffen sind laut Alpine Container ohne sshd, Systeme mit PasswordAuthentication no, gesperrte Konten und Abbilder, die per cloud-init Passwortanmeldungen abschalten.
Wie kritisch ist das?
Die CVSS-Bewertung von 8.1 bildet die hohe Angriffskomplexität ab, also die nötigen Bedingungen. Trifft die Konfiguration zu, reicht laut Alpine eine einzige Verbindung, um ohne Passwort angemeldet zu sein. Die Rechte entsprechen dann dem übernommenen Konto. Die Zahl der beobachteten Versuche ist noch klein, zeigt aber, dass Angreifer kurz nach der Veröffentlichung gezielt scannen.
Was sollten Admins jetzt tun?
- Inventar: alle Systeme mit Alpine oder anderer musl-Distribution und laufendem sshd erfassen, auch VMs aus tiny-cloud-Abbildern.
- Mit
apk upgrade -U -aaktualisieren und sshd mitrc-service sshd restartneu starten. Ohne Neustart läuft der alte Daemon weiter. - Wo das Update nicht sofort geht,
PasswordAuthentication nosetzen, vorher die Anmeldung per Schlüssel testen. - In
/var/log/messagesnach Zeilen „Accepted password for“ bei Konten ohne Passwort suchen, etwa alpine, root oder reine Schlüsselkonten. - doas-Nutzung, neu angelegte Konten, Dateien und authorized_keys auf erreichbaren Maschinen prüfen. Lässt sich eine fremde Anmeldung nicht ausschließen, rät Alpine, das System als kompromittiert zu behandeln.
Einordnung für Unternehmen
Alpine steckt in vielen kleinen Appliances, Cloud-VMs und Jump-Hosts, die selten im Blick sind. Docker-Images auf Alpine-Basis sind meist nicht betroffen, weil darin kein sshd läuft. Die Lehre aus dem Fall gilt über Alpine hinaus: SSH-Zugänge aus dem Internet sollten nur Schlüssel akzeptieren und nicht direkt erreichbar sein.
Passende Anleitungen auf S-EDV
- OpenSSH 10.6p2: Passwort-Umgehung auf Alpine und anderen musl-Systemen
- SSH-Hardening Deep-Dive: sshd_config, Match-Blöcke und ssh-audit für KMU-Server
- VPS absichern und härten: UFW, SSH-Schlüssel und Fail2Ban unter Ubuntu und Debian
