Folgen Eine hochgradige Schwachstelle in OpenSSH kann es nicht authentifizierten, entfernten Angreifern ermöglichen, die Passwortauthentifizierung auf bestimmten Linux-Systemen zu umgehen, indem sie ein überlanges Passwort einreichen. Verfolgt als CVE-2026-123158 und unter dem Namen SSHhole bekannt, hat die Schwachstelle einen CVSS 3.1-Score von 8,1 und betrifft hauptsächlich Linux-Umgebungen, in denen sshd mit musl libc verknüpft ist und ohne PAM arbeitet. Alpine Linux ist die markanteste betroffene Plattform, da das Standard-Openssh-Server-Paket diese Konfiguration standardmäßig verwendet.
Die Schwachstelle ergibt sich aus einer unerwarteten Interaktion zwischen der OpenSSH-Passwortvalidierung und der crypt()-Implementierung von musl libc. Wenn ein übermäßig langes Passwort eingegeben wird, kann crypt() den String * als Fehler zurückgeben. Einige Linux-Konten, die ohne herkömmliches Passwort konfiguriert sind, speichern ebenfalls * im Passwortfeld von /etc/shadow. Unter verwundbaren Bedingungen kann sshd die übereinstimmenden Werte fälschlicherweise als erfolgreiche Authentifizierung interpretieren.
Ein Angreifer muss das Passwort des Zielbenutzers nicht kennen. Wenn ein exponierter SSH-Dienst die erforderlichen Bedingungen erfüllt, kann ein Angreifer, der den Dienst erreichen kann, sich bei bestimmten Konten mit einem Passwort im anfälligen Längenbereich authentifizieren. Die Auswirkungen hängen von den dem kompromittierten Konto zugewiesenen Berechtigungen ab. Der Zugriff auf ein privilegiertes Dienstkonto oder ein Konto, das über doas oder andere Mechanismen zur Privilegienerweiterung verfügt, könnte zu einer vollständigen Systemkompromittierung führen.
OpenSSH hat das Problem in Portable OpenSSH 10.6p2 behoben, das am 5. November 2026 veröffentlicht wurde. Alpine Linux hat gleichzeitig gepatchte OpenSSH-Pakete für alle unterstützten Zweige und mehrere ältere Zweige freigegeben. Das OpenSSH-Team beschreibt die Veröffentlichung als eine kritische Sicherheitslösung für Linux-Systeme, die musl libc verwenden und bei denen PAM deaktiviert ist.
Öffentliche Reproduktionsumgebungen und Proof-of-Concept-Materialien sind bereits verfügbar. Bis zum 6. November 2026 berichten die geprüften Quellen jedoch nicht von bestätigten Ausnutzungen der Schwachstelle in realen Angriffen, und die Schwachstelle wurde nicht zum CISA-Katalog bekannter ausgenutzter Schwachstellen hinzugefügt.
Organisationen können ihre Verteidigung gegen auftauchende Authentifikations-Bypass-Schwachstellen mit der AI-Native Detection Intelligence Platform von SOC Prime stärken, die Bedrohungsjagd und Erkennungsingenieurwesen in SIEM-, EDR-, XDR- und Data-Lake-Umgebungen beschleunigt.
Sicherheitsteams können auch Prime Architect verwenden, um Schwachstelleninformationen in Jagd-Queries und Erkennungslogik umzuwandeln, die auf ihre verfügbaren SSH-, Authentifizierungs-, Endpunkt- und Netzwerktelemetrie zugeschnitten sind.
Erkennen Sie CVE-2026-123158, indem Sie erfolgreiche SSH-Anmeldungen basierend auf Passwörtern zu Konten überwachen, die normalerweise nur Schlüssel-authentifiziert werden, ungewöhnliche Authentifizierungsversuche mit abnormal langen Passwörtern, unerwarteten Remotezugriff auf Dienstkonten und Post-Authentifizierungsaktivitäten, die nicht mit dem normalen Verhalten des Kontos übereinstimmen.
Erkennungsinhalte sind möglicherweise nicht für jede CVE verfügbar. Überprüfen Sie die SOC Prime Platform auf die aktuelle Abdeckung. Wenn relevante Erkennungen noch nicht verfügbar sind, überprüfen Sie erneut, da neue Bedrohungsinformationen und Erkennungsinhalte kontinuierlich hinzugefügt werden.
CVE-2026-123158-Analyse
CVE-2026-123158 betrifft OpenSSH sshd vor Portable OpenSSH 10.6p2, wenn es auf Linux mit musl libc läuft und Passwortauthentifizierung ohne PAM erfolgt. Die CVE trägt einen CVSS 3.1-Score von 8,1 mit dem Vektor AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H, was eine fernausnutzbare Schwachstelle ohne vorherige Privilegien oder Benutzerinteraktion, aber mit einer spezifischen System- und Kontokonfiguration reflektiert.
Die Ursache liegt in der Interaktion zwischen OpenSSH und der von musl libc bereitgestellten Passwort-Hash-Funktion.
Auf Systemen, auf denen PAM deaktiviert ist, führt sshd die Passwortvalidierung mithilfe der crypt()-Funktion des Systems durch. Für ein typisches Konto enthält /etc/shadow einen kryptografischen Passwort-Hash, und der aus dem eingereichten Passwort des Benutzers generierte Wert wird mit diesem gespeicherten Hash verglichen.
musl libc verhält sich anders, wenn das eingegebene Passwort seine unterstützte Eingabelänge überschreitet. Für Passwörter, die länger als 256 Bytes sind, gibt crypt() * als Fehlerwert zurück, anstatt eines normalen Passwort-Hashes.
Das Problem entsteht, weil * auch häufig in /etc/shadow für Konten verwendet wird, die kein herkömmliches Passwort konfiguriert haben.
Wenn ein anfälliges sshd ein überlanges Passwort für eines dieser Konten erhält, kann der Authentifizierungsablauf effektiv das von crypt() zurückgegebene * mit dem im Schatteneintrag des Kontos gespeicherten * vergleichen. Die Werte stimmen überein, und die Authentifizierung kann fälschlicherweise gelingen.
Die CVE-Beschreibung besagt, dass für betroffene Kontokonfigurationen Passwörter zwischen 256 und 1024 Zeichen zu einer erfolgreichen Authentifizierung führen können. Unabhängige Reproduktionen beschreiben Passwörter, die die normale 256-Byte-Grenze überschreiten, als ausreichend, um die anfällige Bedingung auszulösen.
Die Schwachstelle ist daher nicht ein universeller Passwort-Bypass, der jede OpenSSH-Bereitstellung betrifft.
Mehrere spezifische Bedingungen müssen zutreffen.
Erstens muss der Server musl libc verwenden. Alpine Linux ist das primäre Beispiel im Mainstream, obwohl auch andere eingebettete oder minimale Linux-Umgebungen musl verwenden können.
Zweitens muss sshd Benutzer ohne PAM authentifizieren. AlPine’s Standard-Openssh-Server-Paket wird ohne PAM gebaut, während die alternative Konfiguration openssh-server-pam geschützt ist, wenn UsePAM yes aktiviert ist.
Drittens muss die Passwortauthentifizierung aktiviert sein. PasswordAuthentication yes ist die relevante Konfiguration. Systeme, die nur für die Authentifizierung mit öffentlichen Schlüsseln mit PasswordAuthentication no konfiguriert sind, sind nicht dem dokumentierten Angriffsweg ausgesetzt.
Schließlich benötigt der Angreifer ein Konto, dessen Passwortfeld *. enthalten Es kann sich um nur Schlüsselbenutzer handeln, Konten ohne Passwörter, einige über Verzeichnisdienste bereitgestellte Identitäten und bestimmte Cloud-Image-Benutzer.
Alpine deutet auch auf eine zusätzliche Bedingung hin: Mindestens ein lokales Konto muss einen Passwort-Hash im $5$- oder $6$-Stil enthalten, damit der verwundbare Authentifizierungsweg wie beschrieben funktioniert.
Dem Root-Konto gebührt besondere Aufmerksamkeit. Alpine speichert häufig root:*, aber OpenSSHs Standard PermitRootLogin prohibit-password verhindert die Passwortauthentifizierung direkt zu root. Daher ermöglicht eine standardmäßige Alpine-Installation nicht automatisch die direkte Root-Anmeldung über diesen Fehler.
Dieser Schutz beseitigt nicht das breitere Risiko. Wenn ein anderes Konto mit * im Passwortfeld aus der Ferne zugänglich ist und über administrative Rechte durch doas, sudo, Container-Fähigkeiten oder andere privilegierte Mechanismen verfügt, kann eine erfolgreiche Authentifizierung dennoch einen Weg zur vollständigen Systemkompromittierung bieten.
Die offiziellen Tiny-Cloud-Images von Alpine sind besonders relevant. Sicherheitsforschungen identifizierten Versionen, bei denen das alpine-Konto die anfälligen Bedingungen erfüllen und auch doas verwenden konnte, um erhöhte Privilegien zu erlangen. Dies zeigt, warum Verteidiger die Kontoberechtigungen bewerten sollten, anstatt davon auszugehen, dass die Schwachstelle entweder harmlosen Benutzerzugang oder automatischen Rootzugang in jeder Umgebung bietet.
Linux-Distributionen auf glibc-Basis wie Debian, Ubuntu und RHEL sind nicht von dieser spezifischen Schwachstelle betroffen, da das anfällige Verhalten von der Passwort-Hashing-Implementierung von musl libc abhängt. Systeme, die PAM zur Überprüfung von SSH-Passwörtern verwenden, sind ebenfalls außerhalb der dokumentierten anfälligen Konfiguration.
Container erfordern eine ähnliche Qualifikation. Alpine wird häufig als Container-Basisimage verwendet, aber gewöhnliche Container, die sshd nicht ausführen, sind durch diesen Angriffsweg nicht gefährdet. Die Hauptsorge betrifft Container, Appliances, Entwicklungsumgebungen oder Legacy-Systeme, die einen SSH-Server explizit installieren und exponieren.
Die PoC-Landschaft für CVE-2026-123158 hat sich schnell entwickelt. Öffentliche Reproduktionslabors werden direkt durch die Schwachstellenaufzeichnung referenziert, was zeigt, dass Verteidiger davon ausgehen sollten, dass der Authentifikations-Bypass reproduziert werden kann, ohne auf private Exploit-Forschung zuzugreifen. Das erhöht die Dringlichkeit der Behebung materiell, obwohl noch keine bestätigte böswillige Ausnutzung gemeldet wurde.
Die Schwachstelle wurde von Özgün Kültekin von Wakefield gemeldet. OpenSSH veröffentlichte öffentlich die Version 10.6p2 mit dem Sicherheits-Workaround am 5. November 2026. Die geprüften primären Quellen geben nicht das genaue Datum an, an dem der Forscher das Problem ursprünglich entdeckt oder privat gemeldet hat.
Der Fix von OpenSSH fügt eine Validierung hinzu, die verhindern soll, dass Fehlerwerte und ungültige kurze Passwort-Hashes während der Passwortauthentifizierung akzeptiert werden. OpenSSH stellt fest, dass es die zugrunde liegende Ursache als außerhalb von sshd liegend betrachtet, aber da die Bedingung durch den SSH-Server ausnutzbar ist, hat das Projekt einen defensiven Workaround in OpenSSH selbst implementiert.
Alpine Linux hat die Korrektur in mehreren Zweigen rückportiert:
| Alpine-Zweig | Gefixtes OpenSSH-Paket |
| 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 |
Administratoren sollten sich eher auf den Status des Distributionspakets als auf das SSH-Versionsbanner allein verlassen. Linux-Distributionen backportieren häufig Sicherheitspatches, ohne die von OpenSSH bei der SSH-Handschlag angezeigte Upstream-Version zu ändern. Ein Server, der eine ältere Versionskennung anzeigt, kann daher bereits den Vendor-Fix enthalten.
Zur Erkennung von CVE-2026-123158 sollten Verteidiger SSH-Authentifizierungstelemetrie priorisieren. Ein besonders starkes Jagd-Signal ist ein erfolgreicher Passwort-Login bei einem Account, der nur zur Authentifizierung mit öffentlichen Schlüsseln bestimmt ist oder kein verwendbares Passwort konfiguriert hat.
Auf Alpine-Systemen können Administratoren /var/log/messages, zentrale Authentifizierungsprotokolle, SIEM-Aufzeichnungen oder gleichwertige Telemetrie für akzeptierte Passwortevents von unerwarteten Dienstleistungs-, Schlüssel- oder administrativen Konten überprüfen.
Verteidiger sollten erfolgreiche Authentifizierungen mit Quell-IP-Adressen, Anmeldezeiten, Sitzungsdauer, Befehlen, die nach der Anmeldung ausgeführt wurden, Privilegienerhöhung, Änderungen an authorized_keys-, Kontenerstellung-, geplanten Aufgaben- und unerwarteten ausgehenden Netzwerkverbindungen korrelieren.
Netzwerktelemetrie kann auch helfen, exponierte Systeme zu identifizieren. Extern erreichbare SSH-Dienste, die Passwort- oder Tastatur-interaktive Authentifizierung anbieten, sollten höhere Priorität bei den Abhilfemaßnahmen erhalten, insbesondere wenn das zugrunde liegende System Alpine oder eine andere musl-basierte Distribution ist.
Derzeit gibt es keine kampagnenspezifischen CVE-2026-123158-IOCs wie bestätigte Angreifer-IP-Adressen, Domains, Malware-Hashes oder Kommando-und-Kontrollinfrastruktur. Das Fehlen statischer Indikatoren macht das Überwachung von Verhaltensänderungen bei der SSH-Authentifizierung und nachfolgenden Sitzungsaktivitäten besonders wichtig.
CVE-2026-123158-Abschwächung
Die primäre Abhilfe besteht darin, OpenSSH 10.6p2 oder das vom Linux-Distributionsanbieter bereitgestellte Korrekturpaket zu installieren. Alpine-Administratoren sollten das vollständige System mit aktuellen Paket-Repositories aktualisieren und anschließend sshd neu starten. Das Aktualisieren des Pakets allein ersetzt nicht den bereits laufenden SSH-Daemon-Prozess.
Organisationen, die auf Alpine-basierte Container setzen, sollten jedes Image, das openssh-server installiert, neu erstellen und bereitstellen. Einfach das Host-Betriebssystem zu aktualisieren, patcht keine anfälligen OpenSSH-Pakete, die in Containerbildern eingebunden sind.
Administratoren sollten auch die Exposition identifizieren, bevor sie annehmen, dass jeder Alpine-Host anfällig ist. Wichtige Überprüfungen umfassen:
- Bestimmen, ob der Host musl libc verwendet.
- Überprüfen, ob sshd mit deaktiviertem PAM läuft.
- Kontrollieren, ob die Passwortauthentifizierung aktiviert ist.
- Login-fähige Konten identifizieren, deren /etc/shadow-Passwortfeld * ist.
- Überprüfen, welche Berechtigungen diesen Konten zugewiesen sind.
- Überprüfen der installierten OpenSSH-Version im Vergleich zur korrigierten Version des Distributionspakets.
Wenn sofortiges Patchen nicht möglich ist, sollten Organisationen die SSH-Passwortauthentifizierung deaktivieren.
Konfigurieren:
PasswordAuthentication no
und, soweit zutreffend:
KbdInteractiveAuthentication no
Administratoren sollten sicherstellen, dass die Authentifizierung mit öffentlichen Schlüsseln funktioniert, bevor diese Konfiguration angewendet wird, um den Verlust legitimen administrativen Zugriffs zu vermeiden.
Die SSH-Konfiguration sollte dann validiert und der Daemon neu geladen oder neu gestartet werden. Danach sollte eine externe Verifizierung bestätigen, dass der Server nur Authentifizierung mit öffentlichen Schlüsseln zulässt.
Die Einschränkung der Netzzugänglichkeit bietet zusätzlichen Tiefenschutz. SSH sollte im Allgemeinen nur von vertrauenswürdigen administrativen Netzwerken, VPN-Infrastrukturen, Bastion-Hosts oder expliziten Quell-IP-Zulassungslisten aus erreichbar sein und nicht universell über das Internet exponiert werden.
Organisationen sollten auch in Betracht ziehen, ob SSH überhaupt innerhalb von Containern erforderlich ist. Moderne Orchestrierungsumgebungen bieten in der Regel Alternativen wie docker exec oder kubectl exec, die einen unnötigen remote erreichbaren Authentifizierungsdienst eliminieren.
Für potenziell exponierte Systeme überprüfen Sie historische erfolgreiche Passwortanmeldungen, die vor der Abhilfe erfolgt sind. Achten Sie besonders auf Konten, die ohne Passwörter konfiguriert sind, und Identitäten, die normalerweise ausschließlich mit SSH-Schlüsseln authentifiziert werden sollen.
Wenn eine unerwartete erfolgreiche Anmeldung identifiziert wird, behandeln Sie das Konto als möglicherweise kompromittiert. Überprüfen Sie soweit verfügbar die Shell-Historie, Prozessausführungen, Privilegienerhöhung, neue oder geänderte authorized_keys-Einträge, Benutzer- und Gruppenänderungen, geplante Aufgaben, Startskripte, Paketinstallation und ausgehende Netzwerkverbindungen.
Zugängliche Anmeldeinformationen und Schlüssel des kompromittierten Kontos sollten als möglicherweise gefährdet angesehen und gemäß den Ergebnissen der Untersuchung geändert werden. Wenn das Konto administrative Privilegien hatte, sollten Verteidiger die Untersuchung auf den gesamten Host und alle Systeme erweitern, die mit dort gespeicherten Anmeldeinformationen erreichbar sind.
Öffentliches Proof-of-Concept-Material bedeutet, dass Organisationen nicht auf Hinweise auf weit verbreitete Angriffe warten sollten, bevor der Fix angewendet wird. Die Ausnutzungs-Voraussetzungen begrenzen die anfällige Population, aber Systeme, die diese Bedingungen erfüllen, können remote ohne Kenntnis eines gültigen Passworts zugegriffen werden.
FAQ
Was ist CVE-2026-123158 und wie funktioniert es?
CVE-2026-123158 ist ein Passwort-Authentifizierungs-Bypass, der OpenSSH sshd auf Linux-Systemen betrifft, die musl libc ohne PAM verwenden. Wenn ein übermäßig langes Passwort an die crypt()-Funktion von musl übergeben wird, kann es * als Fehlerwert zurückgeben. Wenn das Zielkonto ebenfalls * in /etc/shadow gespeichert hat, können verwundbare sshd-Konfigurationen die Werte fälschlicherweise als übereinstimmend behandeln und die Authentifizierung zulassen.
Wann wurde CVE-2026-123158 erstmals entdeckt?
Die Schwachstelle wurde von Özgün Kültekin von Wakefield gemeldet. OpenSSH veröffentlichte den Sicherheitsfix in Portable OpenSSH 10.6p2 am 5. November 2026, und die CVE wurde am selben Tag öffentlich. Die derzeit überprüften primären Hinweise geben nicht das genaue Datum der ursprünglichen privaten Entdeckung des Forschers an.
Welche Auswirkungen hat CVE-2026-123158 auf Systeme?
Erfolgreiche Ausnutzung ermöglicht einem nicht authentifizierten entfernten Angreifer, sich ohne Kenntnis des Passworts bei einem qualifizierenden Konto anzumelden. Die daraus resultierenden Auswirkungen hängen von den Berechtigungen dieses Kontos ab. Die Kompromittierung eines Dienst- oder Standardkontos kann Daten und Anwendungsressourcen gefährden, während der Zugriff auf ein Konto mit doas-, sudo- oder gleichwertigen Berechtigungen potenziell zu einer vollständigen Systemkompromittierung führen kann.
Kann CVE-2026-123158 mich im Jahr 2026 noch betreffen?
Ja. Verwundbare OpenSSH-Installationen bleiben ausgesetzt, bis sie gepatcht oder die Passwortauthentifizierung deaktiviert wird. Die höchstrisikobehafteten Systeme sind musl-basierte Linux-Umgebungen wie Alpine Linux, die sshd ohne PAM ausführen und qualifizierende passwortlose Konten enthalten. Öffentliches Reproduktionsmaterial existiert, obwohl bis zum 6. November 2026 keine bestätigte Ausnutzung in der Praxis gemeldet wurde.
Wie kann ich mich vor CVE-2026-123158 schützen?
Aktualisieren Sie auf OpenSSH 10.6p2 oder Ihr gepatchtes Paket der Distribution und starten Sie sshd neu. Wenn das Patchen nicht sofort abgeschlossen werden kann, deaktivieren Sie Passwort- und tastaturinteraktive Authentifizierung, beschränken Sie die SSH-Exposition auf vertrauenswürdige Netzwerke und überprüfen Sie erfolgreiche Passwortanmeldungen auf verdächtige Aktivitäten. Administratoren sollten weiterhin die Anbieterhinweise auf aktualisierte Details zu CVE-2026-123158 überwachen, während sich die Exploit-Intelligenz entwickelt.
