Ein Passwort mit mehr als 256 Zeichen soll eigentlich besonders sicher sein. Bei bestimmten Linux-Servern bewirkt ein überlanges Passwort derzeit das Gegenteil: Es kann die Anmeldung an einem Konto ermöglichen, das überhaupt keine Passwortanmeldung zulassen sollte. Am 5. November 2026 haben OpenSSH und Alpine Linux deshalb Sicherheitsupdates veröffentlicht. Die Schwachstelle wird als CVE-2026-123158 geführt.
Was steckt hinter der OpenSSH-Lücke?
Betroffen ist das Zusammenspiel zwischen dem SSH-Server OpenSSH und der C-Bibliothek musl, die unter anderem Alpine Linux verwendet. Unter bestimmten Bedingungen akzeptiert der SSH-Dienst Passwörter von 257 bis 1.024 Byte Länge, ohne dass der Angreifer das tatsächliche Passwort kennen muss.
Der Fehler entsteht bei der Passwortprüfung ohne PAM. Linux-Konten, die kein Passwort besitzen und beispielsweise nur per SSH-Schlüssel erreichbar sein sollen, können in der Passwortdatenbank mit einem Sternchen (*) gekennzeichnet sein. Die musl-Funktion crypt() liefert bei überlangen Eingaben für bestimmte Hashverfahren ebenfalls * als Fehlerwert zurück. OpenSSH kann diesen Rückgabewert dann fälschlich als Übereinstimmung mit dem gespeicherten Kontoeintrag werten.
Die problematische Kombination geht auf Änderungen aus dem Jahr 2016 zurück. Entdeckt und gemeldet wurde der Fehler von Sicherheitsforscher Özgün Kültekin. OpenSSH hat am 5. November die Version 10.6p2 mit einer Gegenmaßnahme veröffentlicht.
Alpine Linux ist weit verbreitet – besonders bei Docker
Alpine zählt zu den bekanntesten schlanken Linux-Distributionen für Container. Das offizielle Alpine-Image auf Docker Hub kommt auf mehr als eine Milliarde kumulierte Downloads; Docker Hub weist zudem rund 28,2 Millionen Downloads innerhalb einer erfassten Woche aus. Hinzu kommen zahlreiche Anwendungen, die Alpine als Basisimage verwenden.
Diese Zahlen zeigen die Verbreitung, aber nicht die Zahl gefährdeter Systeme. Docker-Pulls sind weder einzelne Server noch eindeutige Installationen. Vor allem betreiben viele Alpine-basierte Container gar keinen SSH-Server. Wer etwa nur eine Webanwendung in einem Container ausführt, ist deshalb nicht automatisch betroffen.
Welche Installationen sind tatsächlich gefährdet?
Alpine nennt mehrere Voraussetzungen, die zusammenkommen müssen: Ein OpenSSH-Server prüft Passwörter ohne PAM, PasswordAuthentication ist aktiviert, mindestens ein Konto besitzt den Passworteintrag * und mindestens ein anderes lokales Konto verfügt über einen passenden Passwort-Hash im Format $5$ oder $6$. Außerdem muss das betreffende Konto grundsätzlich für eine SSH-Anmeldung zugelassen sein.
Das ist beispielsweise bei eigens eingerichteten SSH-Schlüsselkonten relevant. Auch bestimmte Alpine-Cloud-Images können nach einer Änderung der Benutzerkonfiguration verwundbar werden. Für das Root-Konto greift in Standardkonfigurationen dagegen häufig die zusätzliche SSH-Sperre PermitRootLogin prohibit-password.
Andere musl-basierte Linux-Systeme, beispielsweise bestimmte OpenWrt-, Buildroot- oder Yocto-Installationen, müssen abhängig von ihrer SSH-Konfiguration ebenfalls geprüft werden. Linux-Systeme mit glibc oder einer Passwortprüfung über PAM sind von diesem konkreten Fehler nicht betroffen.
Interaktive Demonstration des Fehlers
Der Entdecker Özgün Kültekin erklärt auf sshhole.com die Entstehung der Schwachstelle anhand der Änderungen seit 1980. Eine interaktive Gegenüberstellung von Debian mit glibc und Alpine mit musl zeigt direkt im Browser, weshalb ein überlanges Passwort unterschiedlich behandelt wird. Die Demo veranschaulicht den Fehler, ersetzt aber keine Prüfung der eigenen SSH-Konfiguration.
Was Administratoren jetzt tun sollten
Alpine hat korrigierte OpenSSH-Pakete für mehrere Versionen bis zurück zu Alpine 3.16 bereitgestellt. Für die unterstützten Versionszweige 3.22, 3.23 und 3.24 liegen Sicherheitsupdates vor. Wichtig ist dabei: Die Paketinstallation allein reicht nicht, solange noch der alte SSH-Dienst läuft.
apk upgrade -U -a
rc-service sshd restart
Wer nicht unmittelbar aktualisieren kann, sollte Passwortanmeldungen in der SSH-Konfiguration mit PasswordAuthentication no abschalten, die wirksame Konfiguration mit sshd -T prüfen und den Dienst neu starten. Vorher muss ein funktionierender SSH-Schlüsselzugang getestet sein, damit der Zugriff auf den Server erhalten bleibt.
Administratoren öffentlich erreichbarer Systeme sollten außerdem SSH-Protokolle auf ungewöhnliche erfolgreiche Passwortanmeldungen bei eigentlich passwortlosen Konten untersuchen. Bislang ist die tatsächliche Zahl betroffener Server nicht belastbar bekannt.
Ein alter Fehler mit ungewöhnlicher Wirkung
Bemerkenswert ist weniger die Länge des Passworts als der zugrunde liegende Logikfehler: Ein als ungültig gedachter Rückgabewert wird an einer anderen Stelle wie ein gültiger Vergleichswert behandelt. Genau dadurch wird aus einer gesperrten Passwortanmeldung unter bestimmten Voraussetzungen eine erfolgreiche SSH-Sitzung.
Quellen: Alpine Linux: Security Advisory und Docker Hub: Alpine Official Image.
📂
Kategorie
News
Aktuelle Meldungen aus der Tech-Welt – kompakt eingeordnet, ohne Clickbait-Überschriften.
