OpenSSH-Lücke SSHole: Angreifende loggen sich ohne Passwort auf Alpine-Servern ein

Kriminelle brechen seit dem 5. November 2026 über die OpenSSH-Lücke SSHole (CVE-2026-123158) in Linux-Server ein, ohne ein gültiges Passwort zu kennen. Verwundbar sind nur Systeme wie Alpine Linux, die die schlanke C-Bibliothek musl nutzen und Passwörter nicht über PAM prüfen, das Anmelde-Framework vieler Distributionen. Das berichtet BleepingComputer am 9. November unter Berufung auf GreyNoise, Previdian, Defused und watchTower. Mindestens ein Angriff endete mit Root-Rechten. Den Fix liefert OpenSSH 10.6p2.

Wie ein Sternchen OpenSSH aushebelt

SSHole öffnet Konten, deren Passwort per Sternchen gesperrt ist, sobald Angreifende ein Passwort mit mehr als 256 Zeichen senden. Entdeckt hat die Lücke Özgün Kültekin, Forscher bei Wakefield. Das Sternchen steht in /etc/shadow, der Datei mit den Passwort-Hashes. Es sperrt die Anmeldung per Passwort. Root trägt es. Deploy-Konten mit reinem Schlüssel-Login tragen es ebenfalls. Diese Konten gelten als die sicheren. Ausgerechnet sie sind das Ziel.

Die Ursache liegt im Jahr 2016. Damals schloss OpenSSH laut Help Net Security eine Timing-Lücke (CVE-2016-6210), über die sich existierende Benutzernamen ermitteln ließen. Seitdem hasht der SSH-Dienst sshd das eingegebene Passwort auch bei Konten ohne nutzbaren Hash, und zwar mit dem Salt, also dem Zufallswert, eines anderen Kontos. Die musl-Funktion crypt() lehnt seit 2012 SHA-256- und SHA-512-Passwörter über 256 Bytes ab. Im Fehlerfall gibt sie ein Sternchen zurück. Der Dienst vergleicht es mit dem gespeicherten Sternchen. Beide stimmen überein. Die Anmeldung gelingt.

Das Alpine-Linux-Team beschreibt die Folge in seinem Sicherheitshinweis ohne Umschweife. Wer den SSH-Port erreicht, kommt ohne Passwort hinein. Eine Verbindung genügt. Sie klappt jedes Mal. Kültekin testete sshd in allen denkbaren Build-Varianten mit rund 17.600 ungewöhnlichen Anmeldeversuchen. Nur der musl-Build ohne PAM ließ Logins durch, die er hätte abweisen müssen. Geholfen haben ihm nach eigener Aussage ganze Schwärme von KI-Agenten.

Das OpenSSH-Team sieht die eigentliche Ursache außerhalb von sshd, wie die Release Notes zu OpenSSH 10.6p2 festhalten. Es entschärft den Fehler trotzdem im eigenen Code, weil er dort ausnutzbar ist. Das Update gilt als kritischer Sicherheits-Workaround. Zwei Projekte trafen je eine vernünftige Entscheidung. Zusammen ergeben sie eine offene Tür.

Alpine trifft es, Debian nicht

Verwundbar sind OpenSSH-Versionen vor 10.6p2 auf Linux-Systemen mit musl, die Passwörter nicht über PAM prüfen, berichtet Help Net Security. Für einen Angriff müssen drei Bedingungen zusammenkommen. Die Passwort-Anmeldung muss aktiv sein, was in OpenSSH der Standard ist. Ein Konto muss im Passwortfeld nur das Sternchen tragen. Ein zweites lokales Konto braucht einen echten Hash. Laut SOCRadar passen Konten mit reinem Schlüssel-Login ins Raster, ebenso Konten, die über musl-nscd aus einem Verzeichnisdienst stammen.

Root trägt das Sternchen laut Help Net Security etwa seit Alpine 3.16. Die Voreinstellung PermitRootLogin von OpenSSH hält Root trotzdem draußen, solange niemand sie geändert hat. Das schützt nur den direkten Weg. SOCRadar sieht das größere Risiko woanders. Gemeint ist der indirekte Weg zu Root. Auf Alpines offiziellen Images für AWS und Azure heißt das Standardkonto alpine. Es darf doas, ein schlankes Gegenstück zu sudo, ohne Passwort nutzen. Damit ist das Konto faktisch Root, so Kültekin. SOCRadar nennt als betroffen die tiny-cloud-Images in den Versionen 3.18.11 bis 3.24.3.

Die Tabelle zeigt, welche Systeme laut Kültekin und Help Net Security betroffen sind und welche nicht.

Vom Patch zum Root in 40 Stunden

GreyNoise registrierte den ersten erfolgreichen SSHole-Angriff in freier Wildbahn am 7. November 2026 um 00:46 UTC, rund 40 Stunden nach dem Fix. OpenSSH 10.6p2 war am 5. November erschienen. Exploit-Code tauchte laut BleepingComputer etwa vier Stunden später auf. Am selben Tag begannen erste Angriffsversuche. GreyNoise zählte 16 erfolgreiche Angriffsketten aus sechs IP-Adressen. Repräsentativ für das Gesamtgeschehen seien diese Fälle nicht, betont das Unternehmen.

Dieses Bild wurde mit KI generiertProviderhiggsfieldModellgpt_image_2_5 flare high 1k 16:9PromptSoft clay 3D render, low front-facing view across a tabletop. On the left sits a small clay box with a green checkmark labeled "Patch". In the middle stands a large clay hourglass with sand running through it. On the right is a small clay server with a slightly open door, and a red clay crown-shaped badge labeled "root" floats above it. A thin clay path connects the three objects. Pastel teal, warm orange and soft red palette, gentle studio lighting, shallow depth of field, matte fingerprint-like clay texture, no people, no numbers. No watermark, no signature.

Previdian meldete schon früher einen Treffer. Der erste Versuch kam laut Gründer Ryan Dewhurst weniger als neun Stunden nach Veröffentlichung der CVE. Auf einem Honeypot, einem Köder-Server mit echtem Alpine Linux und OpenSSH, endete ein Angriff mit Root-Zugang. Die Quelle lag in Japan. Ihre IP-Adresse lautete 89.116.89[.]18. Die Gegenseite schickte überlange Passwörter. Danach liefen id, uname und hostname. Bis zum 6. November zählte Previdian acht Versuche, alle von dieser Adresse. Laut BleepingComputer vom 9. November zeigen Previdians Sensoren inzwischen 20 Versuche von 13 IP-Adressen aus neun Ländern.

Das Offensiv-Sicherheitsunternehmen watchTower beobachtete am 6. November Angriffe aus dem Umfeld von Botnetzen und Kryptomining. Defused aus Finnland sah am Wochenende vom 7. auf den 8. November nur wenige Akteure. Breit gestreut war das laut Defused nicht. GreyNoise registrierte zudem 27,5 Millionen Scans auf Port 22 und 20,1 Millionen SSH-Sitzungsversuche. Ob SSHole dahintersteckt, ist nicht bestätigt.

Dewhurst sieht Angriffe durch KI schneller werden. SSHole sei außerdem besonders trivial auszunutzen, sagte er Help Net Security. Das habe die Zeitspanne bis zum Angriff stark verkürzt. Patchfenster messen sich jetzt in Stunden.

TAC Agent: Implantat ohne Auftrag

Bei einem SSHole-Angriff erlangte die Gegenseite Root-Rechte und installierte TAC Agent, einen in Python geschriebenen Agenten zur Fernsteuerung, berichtet GreyNoise. Sein Command-and-Control-Server, der Steuerrechner der Angreifenden, lag unter tac.vpnla[.]org. Das Implantat erreichte ihn nie. Einen Auftrag bekam es deshalb nicht. Der Spion blieb ohne Funkgerät.

Die Angriffe in den GreyNoise-Netzen folgten einem klaren Muster. Erkundet wurden System und Container. Abgefragt wurden auch Cloud-Metadatendienste, über die virtuelle Maschinen Angaben zu sich selbst beziehen. Dazu kamen Versuche, Passwort-Hashes und Root-SSH-Schlüssel zu lesen. Andere Versuche zielten auf Dateien namens authorized_keys, die Listen erlaubter Anmeldeschlüssel. Ein neuer Eintrag dort sichert dauerhaften Zugang. Ein Patch schließt die Lücke. Einen fremden Schlüssel entfernt er nicht.

TAC Agent führt laut GreyNoise Shell-Befehle aus, späht das System aus, lädt Dateien hoch und herunter und aktualisiert sich selbst. Eingebaute Persistenz fehlt ihm, also die Fähigkeit, einen Neustart zu überdauern. Deshalb richteten die Angreifenden einen Startdienst ein. Kommentare, Logs und Fehlermeldungen des Implantats sind auf Chinesisch. Für eine Zuordnung taugt das laut GreyNoise nur zusammen mit weiteren Indizien.

Brisant ist ein technisches Detail. Eine fehlende Werkzeugprüfung liefert Rückmeldungen, mit denen ein automatisierter Planer seine Befehle anpassen könnte. GreyNoise hält automatisierten Betrieb deshalb für möglich. Die Release Notes von OpenSSH zeigen die Verteidigungsseite. Das Team erhält demnach viele Fehlerberichte aus KI-Modellen. Mehrfach entdeckten andere Forschende einen solchen Fund unabhängig ein zweites Mal. Daraus folgern die Verantwortlichen, dass auch Angreifende diese Fehler finden können. Sie veröffentlichen deshalb vorerst häufiger Updates.

Wie KI-Pipelines Root-Lücken in Serie abarbeiten, zeigte zuletzt der Fall, in dem OpenAI Kernel-Lücken per KI-Pipeline ausnutzte. Schon am 28. April 2026 warnte das Center for Internet Security vor einer anderen OpenSSH-Lücke, über die sich die Authentifizierung umgehen ließ. Sie trägt die Kennung CVE-2026-35414 und betraf Versionen vor 10.3. Die Release-Taktung steigt nicht ohne Grund.

Patchen, neu starten, Logs lesen

Gegen SSHole hilft OpenSSH 10.6p2, allerdings erst nach einem Neustart des SSH-Dienstes. Alpine reagierte schnell. Laut SOCRadar lieferte die Distribution noch am 5. November gepatchte Pakete für alle Zweige von 3.16 bis edge. Ohne sofortiges Update bleibt eine Notbremse. OpenSSH-Entwickler Damien Miller rät auf Mastodon, auf betroffenen Systemen sofort PasswordAuthentication=no zu setzen oder SSH abzuschalten. Den Doppelrat aus Update und geschlossenem SSH kennen Netzwerkteams bereits von den RouterOS-Lücken bei MikroTik.

Die folgenden Schritte fassen die Empfehlungen von SOCRadar und BleepingComputer für betroffene Systeme zusammen.

1. Prüfen Sie, ob das System musl nutzt und sshd ohne PAM läuft.
2. Installieren Sie OpenSSH 10.6p2 oder das gepatchte Paket Ihrer Distribution.
3. Starten Sie sshd danach neu, denn laut SOCRadar nimmt der alte Prozess sonst weiter Verbindungen an.
4. Durchsuchen Sie /var/log/messages nach Einträgen „Accepted password for“ bei Konten ohne Passwort, etwa alpine, root oder reinen Schlüssel-Konten.
5. Kontrollieren Sie authorized_keys, die Nutzung von doas und neu angelegte Benutzerkonten.
6. Suchen Sie nach Dateien und Startdiensten von TAC Agent.

Lässt sich ein unberechtigter Login nicht ausschließen, sollten Sie die Maschine laut SOCRadar als kompromittiert behandeln.

Tipp: Proof-of-Concept-Exploits, also Demonstrationscode für SSHole, kursieren auf GitHub, doch Previdian warnt, dass sie ungeprüft sind und Schadsoftware enthalten können.

Wie schnell Distributionen bei Linux-Lücken nachlegen müssen, zeigte zuletzt Copy Fail mit seinen Eil-Patches. Offen ist bei SSHole die Einstufung durch die CISA. Laut Help Net Security fehlte die Lücke am 6. November noch im KEV-Katalog der US-Behörde, der Liste aktiv ausgenutzter Schwachstellen. Previdian ist weiter. Das Unternehmen führt die Lücke bereits auf einer eigenen Liste. Für Alpine-Server zählt bis dahin der Neustart von sshd mehr als jede Einstufung.