Portable OpenSSH 10.6p2 erschien am 5. November 2026, und eine Zeile im Changelog wiegt schwerer als die übrigen zwanzig: sshd(8) erlaubt auf Linux-Systemen, die gegen die musl-C-Bibliothek gebaut sind und ohne PAM-Unterstützung laufen, keine Umgehung der Passwort-Authentifizierung mehr.
Das Projekt nennt es einen "kritischen Sicherheits-Workaround", und die Formulierung ist mit Bedacht gewählt. Nach Lesart von OpenSSH liegt der Fehler nicht bei OpenSSH: "Wir betrachten die Ursache dieses Fehlers als außerhalb von sshd liegend, aber er ist über sshd ausnutzbar und kann dort verhindert werden." Gemeldet wurde er von Özgün Kültekin von Wakefield (wakefield.co), einem KI-Sicherheitsunternehmen.
WER BETROFFEN IST
Die betroffene Menge ist eng und präzise – deshalb nennt das Projekt den Fehler nischig, und deshalb nennt es ihn gravierend. Im Scope ist ein Host, der sshd auf musl libc betreibt und die Passwort-Authentifizierung nicht über PAM führt. Alpine Linux ist der prominente Fall, und seine Entwickler veröffentlichten parallel zur OpenSSH-Warnung eine eigene. glibc-Distributionen – Debian, Ubuntu, RHEL, Fedora, SUSE und Derivate – liegen außerhalb des beschriebenen Kreises. Builds mit aktivem PAM ebenfalls.
Was im Kreis bleibt, ist in der Summe nicht klein. Alpine ist die Standardbasis eines sehr großen Teils aller Container-Images, das Betriebssystem auf Routern, Appliances und Embedded-Geräten und das Hostsystem auf vielen kleinen Servern. Jede dieser Maschinen, die sshd mit eingeschalteter Passwort-Authentifizierung betreibt, ist ein Kandidat. Systeme, die ausschließlich per Schlüssel authentifizieren, sind über diesen Pfad nicht exponiert.
WAS JETZT ZU TUN IST
Die Anweisung von OpenSSH-Entwickler Damien Miller, wie heise online sie wiedergibt, war unmissverständlich: betroffene Nutzer sollten "SOFORT" die passwortbasierte Anmeldung abschalten – PasswordAuthentication=no in der sshd_config setzen und sshd neu starten – oder SSH bis zum Patch ganz deaktivieren. Der Fix selbst ist 10.6p2. Für Alpine ist das Update bereits verfügbar; heise merkt an, dass andere Distributionen und viele OpenSSH-Download-Server zum Redaktionsschluss noch 10.6p1 auslieferten. Prüfen Sie also, was Sie tatsächlich geladen haben, statt dem Versionsverzeichnis zu vertrauen.
Eine kurze Triagereihenfolge auf jedem verdächtigen Host:
sshd -V # was wirklich installiert ist sshd -T | grep -i passwordauthentication # ist Passwort-Auth überhaupt an ldd /usr/sbin/sshd | grep -i musl # gegen welche libc gelinkt
Ist Passwort-Authentifizierung an und das Binary musl-gelinkt, ist die Antwort in beiden Fällen dieselbe: Passwort-Auth jetzt abschalten, dann patchen.
WIE SCHNELL DAS GING
Laut heise erfuhr das OpenSSH-Projekt erst am Tag vor der Veröffentlichung von dem Problem, als ein Wakefield-Mitarbeiter es meldete – und das Team beeilte sich vor allem deshalb, weil es befürchtete, andere, feindliche Akteure könnten denselben Fehler mit KI-Unterstützung rasch finden. Für Infrastruktur dieser Tragweite ist das eine außergewöhnliche Wendung: OpenSSH 10.6 erschien am 6. Oktober 2026, 10.6p2 kam 30 Tage später als außerplanmäßiger Patch.
DER TEIL, DER DEN FEHLER ÜBERDAUERN WIRD
Die Vorbemerkung der Release Notes ist das eigentliche Dokument. Dort steht:
"In jüngster Zeit hat das OpenSSH-Team eine große Zahl von Sicherheitsfehlerberichten erhalten, viele davon sind Funde von KI-Modellen oder mit KI-Unterstützung erstellt. Während sich viele KI-Berichte im Kontext eines realistischen Bedrohungsmodells als ohne Sicherheitswirkung erweisen, begrüßen wir diese Berichte sehr – besonders in Kombination mit menschlicher Triage, Analyse, Testfällen und insbesondere mit vorgeschlagenen Fixes."
Und dann der Absatz, der den Auslieferungsmodus ändert:
"Wir haben mehrere Fälle gesehen, in denen ein von KI-Werkzeugen identifizierter Sicherheitsfehler anschließend unabhängig von einem anderen Forscher entdeckt wurde. Das legt nahe, dass Angreifer, die Fehler nicht an Open-Source-Projekte melden, diese Fehler ebenfalls werden finden können. Aus diesem Grund wird das OpenSSH-Team vorerst häufiger Releases veröffentlichen, um Bugfixes schneller zu Nutzern zu bringen, statt sie bis zum nächsten geplanten Release zu sammeln."
Nüchtern gelesen heißt das: Das Maintainer-Team erklärt das Embargo-Modell für tot. Die alte Rechnung – Fixes sammeln, im Takt veröffentlichen, Distributoren Zeit zum Paketieren geben – setzte voraus, dass die Existenz eines Fehlers bis zur Offenlegung leise bleibt. Wenn ein Modell ihn findet und ein Fremder ihn unabhängig findet, ist Leise nicht mehr verfügbar. OpenSSHs Antwort ist Geschwindigkeit statt Geheimhaltung – und das verschiebt echte Arbeit zu den Distributionen und zu Betreibern, die "Patch-Tag" künftig als etwas behandeln müssen, das an jedem Tag stattfinden kann.
Das Changelog von 10.6p2 zeigt dieselbe Politik im Kleinen: Neben dem Bypass-Fix aktiviert es das post-quantische hybride Signaturverfahren ssh-mldsa44-ed25519 als erlaubten CA-Signaturalgorithmus, behebt einen CPU-Spin unter einer Sekunde bei Nutzung von ChannelTimeout und erlaubt restart_syscall(2) in der seccomp-Sandbox (bz4036). Nichts davon ist dringend. Alles davon kam früh.
OFFENE FRAGEN
In den Notizen zu 10.6p2 findet sich zum Redaktionsschluss keine CVE-Nummer, und der eigentliche Defekt – was genau im PAM-losen musl-Pfad einen nicht authentifizierten Client durchlässt – ist nicht öffentlich beschrieben. Ob weitere musl-Distributionen jenseits von Alpine betroffen sind, wird ebenfalls nicht gesagt; angesichts des beschriebenen Mechanismus sollte man das prüfen statt annehmen. All diese Lücken sind als "noch nicht dokumentiert" zu lesen, nicht als "nicht real".
PRÜFEN
Auf jedem Host, der sshd betreibt:
sshd -V sshd -T | grep -i passwordauthentication ldd /usr/sbin/sshd | grep -i musl
Speziell auf Alpine: apk info -v openssh, dann apk upgrade openssh, danach erneut sshd -V und den p2-Build erwarten. Bestätigen Sie, dass Passwort-Auth vor dem Patch aus ist – und dass sie es nach dem Neustart bleibt. Wer heute nicht patchen kann: Die Mitigation kostet eine Zeile und einen Dienstneustart.
