OpenSSH: Passwort-Authentifizierung auf Linux-Systemen mit musl ohne PAM umgehbar, warnt CERT-FR

Top-Secured Cyber-Monitoring: unabhängige Analyse auf Grundlage der unten genannten Quellen. Top-Secured ist mit den genannten Unternehmen nicht verbunden und wird Sie niemals nach Bankdaten oder Passwörtern fragen.

OpenSSH hat am 5. November 2026 Version 10.6p2 veröffentlicht, um eine Umgehung der Passwort-Authentifizierung in sshd zu schließen. Betroffen sind Linux-Systeme auf Basis der C-Bibliothek musl ohne PAM, etwa viele Alpine-Server und -Container. CERT-FR gab am selben Tag eine Warnung heraus und stuft die Ausnutzung als trivial ein, sobald die Bedingungen erfüllt sind.

Was geschah

Am 5. November 2026 hat das OpenSSH-Projekt die portable Version OpenSSH 10.6p2 veröffentlicht, die eine über sshd ausnutzbare Umgehung der Passwort-Authentifizierung behebt. Laut den Versionshinweisen liegt die eigentliche Ursache außerhalb von OpenSSH, sshd wurde aber so angepasst, dass sie nicht mehr greift. Am selben Tag veröffentlichte CERT-FR die Warnung CERTFR-2026-ALE-015: Betroffen sind alle Versionen vor 10.6p2, die Ausnutzung gilt unter den genannten Bedingungen als trivial. Eine CVE-Kennung ist nicht angegeben, und keine der beiden Quellen meldet bislang Angriffe.

Wer betroffen ist

Betroffen sind nur Linux-Systeme, die die C-Bibliothek musl verwenden und sshd ohne PAM betreiben. Laut dem Forscher, der die Lücke entdeckt hat, scheitert die musl-Funktion crypt() bei Passwörtern über 256 Byte und liefert dann * zurück, genau den Wert, der in /etc/shadow ein Konto ohne nutzbares Passwort kennzeichnet. Ein Angreifer kann sich so mit einem überlangen Passwort an einem solchen Konto anmelden (reine Schlüssel-Benutzer oder root auf neueren Alpine-Versionen, so der Forscher), sofern die Passwort-Anmeldung aktiv ist. Der Forscher nennt Alpine, OpenWrt, Buildroot, Yocto und darauf aufbauende Docker-Images. Distributionen auf glibc-Basis, Konfigurationen mit PAM sowie Dropbear sind demnach nicht betroffen.

Was jetzt zu tun ist

  1. Betroffene Systeme finden: ldd --version zeigt auf betroffenen Plattformen musl an; sshd -T | grep -Ei 'usepam|passwordauthentication' prüfen.
  2. Aktualisieren: apk upgrade openssh, danach prüfen, dass ssh -V 10.6p2 meldet. Container-Images mit sshd neu bauen und ausrollen.
  3. Falls das Update warten muss, Passwort-Anmeldungen mit PasswordAuthentication no in einer Datei unter /etc/ssh/sshd_config.d/ abschalten und sshd neu starten (rc-service sshd restart). Andernfalls empfiehlt CERT-FR, den SSH-Dienst zu stoppen.
  4. Nach Spuren suchen: Konten mit * als Passwortfeld auflisten (grep -E '^[^:]+:\*:' /etc/shadow | cut -d: -f1) und in /var/log/messages nach Zeilen Accepted password for zu diesen Konten suchen, wie CERT-FR vorschlägt.

Unsere Einschätzung

Schlanke Images stecken in Containern und Appliances und übernehmen die Voreinstellungen ihres Basissystems, SSH ohne PAM inklusive. Reine Schlüssel-Authentifizierung muss ausdrücklich konfiguriert und nicht einfach angenommen werden: Mit PasswordAuthentication no wäre diese Lücke wirkungslos gewesen.

Quellen

Wie wir unsere Analysen auswählen, prüfen und schreiben →

Ist Ihr eigener Server angreifbar? Machen Sie einen kostenlosen Test — nur öffentliche Informationen, ohne Eindringen:

Server prüfen Website prüfen

Sorgen, dass Ihre Server angreifbar sind? Unser Team prüft, patcht und überwacht Linux- und Cloud-Infrastrukturen rund um die Uhr.

Mit einem Experten sprechen Unsere Managed Server Services →