OpenSSH veröffentlichte am 5. November 2026 Version 10.6p2 mit einem Workaround für eine Authentifizierungsumgehung, die bestimmte Linux-Systeme mit musl und OpenSSH betrifft. Alpine stellt eigene korrigierte Paketstände für seine Zweige bereit. Nach dem Update muss der laufende Dienst sshd neu gestartet werden, damit er die Korrektur lädt. OpenSSH 10.6p2
Welche Voraussetzungen für den Bypass zusammenkommen müssen
Alpines Sicherheitsmeldung beschreibt eine eng umrissene Konfiguration: Der OpenSSH-Server läuft mit musl und ohne PAM, entweder weil das Paket ohne PAM gebaut wurde oder weil UsePAM no gilt. Außerdem muss PasswordAuthentication yes gesetzt sein. Für den angegriffenen Account steht im Passwortfeld ein *; mindestens ein anderer lokaler Account benötigt einen Passwort-Hash mit dem Präfix $5$ oder $6$. Alpines Sicherheitsmeldung
Bei dieser Kombination kann ein Passwort mit 257 bis 1.024 Byte die Umgehung auslösen. Alpine zufolge reicht eine Verbindung zum erreichbaren SSH-Dienst; weitere Versuche sind nicht erforderlich. Der Eintrag * im Passwortfeld eines Accounts bedeutet dabei nicht, dass die Passwortanmeldung für den gesamten SSH-Server abgeschaltet ist.
Alpine stuft Systeme mit PasswordAuthentication no, PAM-gestütztem OpenSSH mit UsePAM yes sowie Accounts mit ! im Passwortfeld für diesen Fehler als nicht betroffen ein. Auch Container ohne laufenden sshd fallen nicht darunter. Der musl-Hinweis grenzt außerdem Dropbear ab: Der Fehler betrifft dort OpenSSH, nicht Dropbear.
Korrigierte Alpine-Pakete und Neustart
Alpine nennt für edge und die Zweige 3.16 bis 3.24 jeweils eine korrigierte openssh-server-Paketrevision:
| Alpine-Zweig | Korrigierte Paketrevision |
| edge | 10.6_p2-r0 |
| 3.24 | 10.3_p1-r2 |
| 3.23 | 10.2_p1-r1 |
| 3.22 | 10.0_p1-r11 |
| 3.21 | 9.9_p2-r1 |
| 3.20 | 9.7_p1-r6 |
| 3.19 | 9.6_p1-r3 |
| 3.18 | 9.3_p2-r4 |
| 3.17 | 9.1_p1-r7 |
| 3.16 | 9.0_p1-r6 |
Für das Update empfiehlt Alpine apk upgrade -U -a. Anschließend muss sshd mit rc-service sshd restart neu gestartet werden. Ein Paketupdate ersetzt den bereits laufenden Daemon nicht.
Ein installiertes Update schützt den laufenden SSH-Dienst erst, wenn sshd neu gestartet wurde.
Falls sich das Update nicht sofort einspielen lässt, nennt Alpine als Übergangsmaßnahme, die Passwortanmeldung mit PasswordAuthentication no abzuschalten und sshd neu zu starten.
Wann Alpine-Tiny-Cloud-Images gefährdet sein können
Alpines offizielle Tiny-Cloud-Artefakte der Versionen 3.18.11 bis 3.24.3 enthalten einen Account namens alpine, dessen Passwortfeld * enthält; für diesen Account ist doas ohne Passwort möglich. Alpine zufolge sind die Images beim ersten Start sicher. Die Voraussetzungen für den Bypass können später erfüllt sein, sobald ein lokaler $6$-Hash vorhanden ist und auch die übrigen Bedingungen zutreffen. Ein erfolgreicher Login als alpine kann dann über doas zu Root-Rechten führen.
Protokolle und Accounts prüfen
Alpine empfiehlt, in /var/log/messages nach Accepted password-Einträgen für Accounts zu suchen, die kein Passwort haben sollten. Administratoren sollten außerdem doas, Benutzerkonten, Dateien und authorized_keys prüfen. Lässt sich ein solcher Login nicht ausschließen, empfiehlt Alpine, das System als kompromittiert zu behandeln.
