Hacker nutzen die OpenSSH-Lücke SSHole, um in Alpine-Linux-Server einzudringen

09.11.2026 4 Min. 7

Angreifer nutzen bereits SSHole (CVE-2026-123158, Schweregrad 8,1 von 10) aus, eine Lücke in OpenSSH, über die man sich auf manchen Linux-Servern mit jedem Passwort anmelden kann, das länger als 256 Zeichen ist. Sie betrifft Systeme mit der C-Bibliothek musl, allen voran Alpine Linux. Die Sicherheitsfirma GreyNoise registrierte den ersten erfolgreichen Einbruch am 7. November um 00:46 UTC, rund 40 Stunden nach Erscheinen des Fixes. Nach der Anmeldung suchten die Eindringlinge nach Passwörtern und Schlüsseln, hinterlegten eigene SSH-Schlüssel und installierten in einem Fall ein Fernsteuerungsprogramm, berichtet BleepingComputer.

Kurz gesagt

  • Betroffen: OpenSSH auf Linux mit musl (Alpine, OpenWrt, Buildroot, Yocto), wenn PAM aus und die Passwortanmeldung an ist. Alpine liefert genau diese Konfiguration standardmäßig aus.
  • Nicht betroffen: Debian, Ubuntu, Fedora und andere glibc-Distributionen, Systeme mit PAM, der SSH-Server Dropbear und OpenBSD.
  • Abhilfe: OpenSSH 10.6p2 oder das gepatchte Paket Ihrer Distribution. Bis dahin die Passwortanmeldung abschalten.

Wie die Umgehung funktioniert

Ein * im Passwortfeld von /etc/shadow bedeutet unter Linux, dass für dieses Konto gar keine Passwortanmeldung möglich ist. Alpine setzt es bei root und bei Nutzern, die sich nur per Schlüssel anmelden. Der Forscher Özgün Kültekin von Wakefield, der den Fehler gemeldet hat, führt ihn zurück auf eine Änderung in musl von 2012: Scheitert die Hash-Funktion für Passwörter, liefert sie * statt eines Fehlers. Sie scheitert an jedem Passwort über 256 Byte. Ein sehr langes Passwort ergibt also *, passt zum gesperrten Konto, und sshd lässt den Angreifer herein. Mit aktiviertem PAM vergleicht sshd die Hashes nicht auf diese Weise, solche Systeme sind sicher.

Der Angriff braucht vier Bedingungen zugleich: sshd mit musl gebaut, PAM deaktiviert, Passwortanmeldung erlaubt und mindestens ein Konto mit * im Passwortfeld. Unter Alpine sind die ersten drei die Voreinstellungen des Pakets openssh-server, und root hat seit Version 3.16 ein *. Die offiziellen Alpine-Images für AWS und Azure haben zudem einen Standardnutzer alpine, der ohne Passwort Befehle als root ausführen darf, sodass eine Anmeldung dort die volle Kontrolle bringt.

Was die Angreifer taten

OpenSSH veröffentlichte Version 10.6p2 mit dem Fix am 5. November. Die Analyse des Forschers erschien am selben Tag, und weniger als eine Stunde später lag Exploit-Code auf GitHub. GreyNoise sah 16 erfolgreiche Angriffsketten von sechs IP-Adressen auf überwachten Systemen und betont, dass dies nur ein Teil der Aktivität ist. Die Eindringlinge prüften, ob sie in einem Container sind, fragten Cloud-Metadatendienste ab, versuchten die SSH-Schlüssel von root und /etc/shadow zu lesen und trugen ihre Schlüssel in authorized_keys für root und den Nutzer alpine ein, um Zugang zu behalten.

Eine Gruppe erlangte root-Rechte, änderte die DNS-Einstellungen, startete einen zweiten, versteckten SSH-Server und installierte TAC Agent, ein Python-Programm mit chinesischen Kommentaren und Meldungen, das Befehle ausführen und Dateien übertragen kann. Bei seinem Steuerserver tac.vpnla[.]org konnte es sich nie anmelden und erhielt keine Aufträge. Auch die Sicherheitsfirmen Previdian und Defused registrierten Versuche, watchTowr brachte die Lücke mit Botnetzen und Krypto-Mining in Verbindung.

So prüfen Sie Ihren Server

  • Stellen Sie fest, was läuft: cat /etc/os-release. Bei Alpine oder einem anderen musl-System weiterlesen. Server mit Ubuntu und Debian sind von diesem Fehler nicht betroffen.
  • Aktualisieren: unter Alpine apk upgrade openssh. Laut Alpine-Sicherheitstracker gibt es gepatchte Pakete für die Zweige 3.19 bis 3.24 und edge.
  • Wenn Sie Schlüssel nutzen, Passwortanmeldung abschalten: PasswordAuthentication no in der sshd-Konfiguration, dann sshd neu starten. Das schließt die Lücke auch vor dem Update.
  • Nach Spuren suchen: erfolgreiche Passwortanmeldungen (grep "Accepted password" /var/log/messages) bei Konten mit * in /etc/shadow, unbekannte Schlüssel in authorized_keys, die Dateien /opt/py3/tac_agent.py und /etc/init.d/tac-agent, Änderungen an /etc/hosts und /etc/resolv.conf sowie ein zusätzlicher SSH-Server auf einem ungewöhnlichen Port (ss -tlnp zeigt offene Ports).
  • Findet sich etwas davon, gilt der Server als kompromittiert: neu installieren und alle Passwörter und Schlüssel ändern, die darauf lagen.

Das betrifft alle, die ein eigenes VPN auf einem günstigen VPS betreiben: Schlanke Alpine-Images sind dafür beliebt. Die meisten Heimrouter mit OpenWrt nutzen für SSH Dropbear und sind nicht betroffen, sofern der Besitzer es nicht durch OpenSSH ersetzt hat. Unsere Anleitung zur VPS-Härtung empfiehlt bereits die SSH-Anmeldung nur per Schlüssel, und diese Einstellung blockiert den Angriff.

opensshalpine linuxlinuxschwachstellehackerhackingcybersicherheitservervpssshgreynoise

Auch lesenswert