OpenSSH-Lücke: Passwort-Bypass auf Alpine und musl-Systemen

Am 5. November 2026 hat das OpenSSH-Projekt die Version 10.6p2 veröffentlicht. Sie schließt eine Authentifizierungslücke, die als CVE-2026-123158 geführt und unter dem Spitznamen „sshole“ bekannt wurde. Angreifer melden sich ohne Kenntnis des Passworts an, indem sie ein überlanges Passwort mit 257 bis 1024 Byte senden. Das BSI hat am 6. November 2026 einen IT-Sicherheitshinweis der Kritikalität 2 (Gelb) herausgegeben. Ein Proof-of-Concept ist öffentlich, der CVSS-Score liegt bei 8,1.

Betroffen ist nicht Linux allgemein, sondern eine konkrete Kombination: OpenSSH vor 10.6p2 auf musl-libc ohne PAM-Passwortprüfung. Das ist die Standardkonfiguration von Alpine Linux – und damit die Basis vieler Container-Images und Appliances. Für KMU und Verwaltung ist das ein Bestandsproblem: Es geht selten um einen großen Server, sondern um Dutzende kleine Systeme ohne aktive Betreuung.

Was passiert ist

Ursache ist das Zusammenspiel von OpenSSH und musl-libc bei der Passwortprüfung ohne PAM. In bestimmten Fehlerfällen liefert musl einen Wert, der dem Kennzeichen für Konten ohne gesetztes Passwort entspricht – das Passwortfeld enthält ein Sternchen. Die Anmeldung gilt damit als erfolgreich, obwohl nie ein gültiges Passwort geprüft wurde. Nach Angaben des Alpine-Projekts genügt eine einzige Verbindung; ein Rateversuch ist unnötig.

Verschärfend wirkt, dass Password-Spraying ohnehin ein Dauerphänomen ist. Das BSI rechnet damit, dass Angreifer die Lücke kurzfristig in ihre Standardwerkzeuge aufnehmen. Verwundbare Systeme sind deshalb auch auf eine bereits erfolgte Kompromittierung zu prüfen.

Wer betroffen ist – und wer nicht

Fünf Bedingungen müssen gleichzeitig erfüllt sein: SSH-Dienst auf musl-basiertem System, UsePAM no, aktive Passwortanmeldung, mindestens ein lokales Konto mit * im Passwortfeld und mindestens ein weiteres Konto mit einem Passwort-Hash im Format $5$ oder $6$.

Unter Alpine ist das häufig der Normalfall: Das Paket openssh-server wird ohne PAM gebaut, die Passwortanmeldung ist voreingestellt aktiv, das Basis-Image führt root mit Sternchen im Passwortfeld. Besonders kritisch sind die offiziellen Tiny-Cloud-Images: Sie enthalten den Benutzer alpine ohne Passwort und mit passwortlosem doas. Wer sich dort anmeldet, erhält unmittelbar Root-Rechte.

Nicht betroffen sind Systeme mit glibc – Debian, Ubuntu, RHEL, SUSE –, Installationen mit aktiver PAM-Passwortauthentifizierung, Systeme mit PasswordAuthentication no sowie Container ohne SSH-Dienst. OpenWrt mit Standard-Dropbear ist ebenfalls sicher.

Fünf Handlungsempfehlungen

1. Bestand aufnehmen: Wo steckt musl?

Prüfen Sie Container-Images, virtuelle Appliances und Firmware auf Alpine-Basis. Ein schneller Test zeigt, ob musl und ein SSH-Dienst vorhanden sind:

ls -l /lib/ld-musl-* 2>/dev/null
rc-service sshd status 2>/dev/null || systemctl status sshd
grep -Ei 'UsePAM|PasswordAuthentication|PermitRootLogin' /etc/ssh/sshd_config

Ergebnisse gehören in eine Liste mit Verantwortlichem und Frist, nicht in ein Ticket ohne Datum. Die kritischen Fälle liegen erfahrungsgemäß am Rand: Monitoring-Sonden, Backup-Appliances, Testsysteme mit Produktionsdaten.

2. Pakete aktualisieren und sshd neu starten

Unter Alpine genügt ein Paket-Update – aber nur, wenn der Dienst danach wirklich neu startet. Ein reines apk upgrade ersetzt den laufenden Prozess nicht:

apk upgrade -U -a
rc-service sshd restart
ssh -V

Korrigierte Pakete stehen für alle Zweige bereit: Alpine 3.24.4, 3.23.8, 3.22.8 und 3.21.10 sowie edge. Maßgeblich ist der Paketstand, nicht die Upstream-Versionsnummer, weil der Fix zurückportiert wurde. Für 3.21 lautet die korrigierte Version etwa 9.9_p2-r1.

3. Images neu bauen, nicht nur Container aktualisieren

Ein aktualisiertes Basis-Image korrigiert keinen laufenden Container. Betroffene Images müssen mit dem korrigierten Paket neu gebaut, in die Registry geschoben und ausgerollt werden. Prüfen Sie auch die Build-Pipelines: Wer apk upgrade ohne Cache-Bereinigung nutzt, zieht unter Umständen alte Pakete.

docker run --rm --entrypoint sh myimage:latest -c 'apk info -v openssh-server'

4. Passwortanmeldung abschalten – dauerhaft

Der wirksamste Workaround ist zugleich die bessere Betriebsgrundlage: Schlüssel statt Passwörter, Root nur per Schlüssel. Testen Sie den Schlüssel-Login, bevor Sie die Passwortanmeldung deaktivieren, und lassen Sie die bestehende Sitzung offen, bis eine neue Anmeldung klappt:

mkdir -p /etc/ssh/sshd_config.d
echo 'PasswordAuthentication no' > /etc/ssh/sshd_config.d/00-keys-only.conf
echo 'PermitRootLogin prohibit-password' >> /etc/ssh/sshd_config.d/00-keys-only.conf
sshd -t && rc-service sshd restart

Ergänzend: SSH-Zugänge auf Managementnetze oder VPN beschränken, Konten mit Sternchen im Passwortfeld inventarisieren, nicht benötigte Konten sperren (Feld ! statt *).

5. Kompromittierung aktiv ausschließen

Erfolgreiche Passwortanmeldungen für Konten ohne Passwort sind der entscheidende Hinweis:

grep 'Accepted password' /var/log/messages
grep '^alpine:' /etc/shadow

Zeigt das Protokoll eine solche Anmeldung, gilt das System als potenziell kompromittiert. Suchen Sie zusätzlich nach neuen Benutzerkonten, Änderungen an authorized_keys, doas-Nutzung und auffälligen Dateiänderungen seit dem 5. November.

Was tun, wenn es schon passiert ist

Erst isolieren, dann untersuchen: System vom Netz nehmen oder eingehende SSH-Verbindungen per Firewall blockieren, Snapshot für die Forensik ziehen, erst danach bereinigen. Ein Patch vor der Sicherung zerstört Beweismittel.

Zugangsdaten erneuern: Alle auf dem System hinterlegten Schlüssel und Tokens gelten als kompromittiert – SSH-Keys, API-Tokens, Datenbank-Zugänge, Zertifikate. Ein Key, der auf einem kompromittierten Host lag, muss überall ersetzt werden, wo er autorisiert war.

Prüfen und melden: Können personenbezogene Daten betroffen sein, greift die Meldepflicht nach Art. 33 DSGVO binnen 72 Stunden. In Kommunen gehört der Vorgang in die Meldekette zur Aufsichtsbehörde.

Die nächsten 30 Tage

Die Lücke ist unangenehm, aber ein guter Anlass für drei überfällige Schritte. Erstens: eine Liste aller musl-basierten Systeme mit SSH-Dienst, inklusive Appliances und Testumgebungen. Zweitens: eine SSH-Baseline – nur Schlüsselauthentifizierung, kein Root-Login per Passwort, Zugriff nur aus dem Managementnetz. Drittens: Image-Rebuild automatisieren, damit ein Sicherheitsupdate nicht davon abhängt, dass jemand an den Container denkt.

Wer diese drei Punkte erledigt, hat nicht nur CVE-2026-123158 geschlossen, sondern die Angriffsfläche dauerhaft reduziert. Genau darauf zielen Password-Spraying-Kampagnen: auf die vielen kleinen Dienste, die seit Jahren unverändert erreichbar sind.

Quellen

• BSI: BITS-H 2026-306241-1032 – OpenSSH-Schwachstelle gefährdet Alpine Linux (06.11.2026)
• Alpine Linux: Security advisory – openssh-server password authentication bypass (05.11.2026)
• OpenSSH: Release Notes 10.6p2 (05.11.2026)
• OX Security: OpenSSH Password Authentication Bypass on Alpine Linux, CVE-2026-123158

Hinweis: Dieser Beitrag wurde mit Unterstützung künstlicher Intelligenz (KI) erstellt.