OpenSSH-Lücke „sshole“: Erst das Inventar, dann der Patch

Am 5. November 2026 hat das OpenSSH-Projekt die Version 10.6p2 veröffentlicht. Sie behebt eine Schwachstelle, die das BSI am 6. November in einer eigenen Meldung aufgegriffen hat: Unter bestimmten Voraussetzungen kann sich ein Angreifer per SSH an einem System anmelden, ohne das Passwort zu kennen. Es reicht, ein überlanges Passwort zu schicken. Die Lücke trägt die Kennung CVE-2026-123158, wurde vom Entdecker „sshole“ getauft und mit einem CVSS-Wert von 8.1 von 10 als „hoch“ eingestuft. Ein Proof-of-Concept ist laut BSI öffentlich verfügbar.

Das klingt zunächst nach einem Thema für Rechenzentren. Tatsächlich betrifft es viele kleinere Unternehmen, die eigene Software betreiben oder betreiben lassen. Denn die betroffene Konstellation steckt häufig dort, wo niemand mehr genau hinschaut: in Container-Images.

Was genau passiert ist#

Laut BSI liegt die Ursache im Zusammenspiel von OpenSSH und der C-Bibliothek musl-libc, und zwar bei der Passwortprüfung ohne PAM (Pluggable Authentication Modules). Bei einer bestimmten Fehlerbehandlung kann ein von musl zurückgegebener Wert mit dem Kennzeichen für Konten ohne gesetztes Passwort übereinstimmen. Die Folge: Die Anmeldung gilt als erfolgreich.

Das OpenSSH-Team beschreibt es in den Release Notes so: Betroffen sind Linux-Systeme, die musl verwenden und bei denen PAM deaktiviert ist. Die eigentliche Ursache sehen die Entwickler außerhalb von sshd, die Lücke ist aber über sshd ausnutzbar und wird deshalb dort abgefangen. Das BSI nennt ausdrücklich Alpine Linux und weitere Produkte als gefährdet.

Wichtig für die Einordnung: Nicht jeder SSH-Server ist betroffen. Klassische Server mit glibc und aktiviertem PAM fallen nicht unter diese Konstellation. Gefährdet ist die Kombination aus musl, Passwort-Anmeldung und fehlendem PAM.

Warum das kleine Unternehmen betrifft#

Alpine Linux ist sehr schlank und wird deshalb gern als Basis für Container-Images genutzt. Viele Webanwendungen, interne Tools, Schnittstellen und auch KI-Anwendungen laufen heute in Containern. Diese Images hat oft irgendwann ein Dienstleister, ein Freelancer oder ein früherer Mitarbeiter gebaut. Danach laufen sie, solange sie funktionieren.

Genau darin liegt das Problem. Die meisten Betriebe können drei einfache Fragen nicht sofort beantworten:

• Welche Container laufen bei uns oder bei unserem Dienstleister überhaupt?
• Auf welchem Basis-Image beruhen sie, und wann wurden sie zuletzt neu gebaut?
• Ist in einem davon ein SSH-Zugang mit Passwort aktiv, vielleicht nur „zum Debuggen“?

Wir hatten vor einer Woche bei den PHP-Lücken im Onlineshop dieselbe Beobachtung gemacht: Der Patch ist selten das Problem. Das Problem ist, dass niemand weiß, wo er eingespielt werden muss.

Ein zweiter Punkt in den Release Notes#

Bemerkenswert ist eine Passage, die mit der Lücke selbst nichts zu tun hat. Das OpenSSH-Team schreibt, es habe zuletzt sehr viele Sicherheitsmeldungen erhalten, viele davon Funde von KI-Modellen oder mit KI-Unterstützung entstanden. Mehrfach sei ein von KI gefundener Fehler kurz darauf unabhängig von anderen entdeckt worden. Daraus folgern die Entwickler, dass auch Angreifer solche Fehler finden können. Deshalb will das Projekt vorerst häufiger Versionen veröffentlichen, statt Korrekturen zu sammeln.

Für Unternehmen heißt das: Die Zeit zwischen Veröffentlichung einer Lücke und ihrer Ausnutzung wird eher kürzer. Wer Updates nur einmal im Jahr bei Gelegenheit einspielt, kommt nicht mehr hinterher. Regelmäßiges Neubauen und Aktualisieren muss Routine werden, nicht Projekt.

Ein Beispiel aus der Praxis#

Ein Handwerksbetrieb hat vor zwei Jahren ein Kundenportal bauen lassen. Es läuft in Containern bei einem Hoster, dazu kam letztes Jahr ein kleiner KI-Assistent für Anfragen. Der Entwickler hat damals in ein Image einen SSH-Zugang mit Passwort eingebaut, um Fehler schneller analysieren zu können. Niemand hat ihn wieder entfernt.

Ob dieses Image auf Alpine beruht und PAM fehlt, weiß im Betrieb niemand. Der Geschäftsführer erfährt von der Lücke vielleicht nie. Genau so entstehen Vorfälle, die mit einem Inventar und einer halben Stunde Prüfung vermeidbar gewesen wären.

Das Gleiche gilt für die Kanzlei mit einem selbst gehosteten Dokumentenportal oder den Onlinehändler mit einer eigenen Schnittstelle zwischen Shop und Warenwirtschaft.

Praxis-Checkliste: OpenSSH und Container prüfen#

1. Inventar anlegen: Listet alle Anwendungen auf, die bei euch oder beim Dienstleister in Containern oder auf eigenen Servern laufen, inklusive KI-Tools.
2. Basis-Images feststellen: Fragt für jedes Image nach, auf welchem Betriebssystem es beruht, zum Beispiel Alpine oder Debian.
3. SSH suchen: Prüft, ob in Containern überhaupt ein SSH-Server läuft. In den meisten Fällen wird er dort gar nicht gebraucht.
4. Passwort-Anmeldung abschalten: Wo SSH nötig ist, nur mit Schlüsseln anmelden und die Passwort-Anmeldung deaktivieren.
5. Updates einspielen: OpenSSH auf 10.6p2 oder das korrigierte Paket eurer Distribution aktualisieren und betroffene Images neu bauen.
6. Erreichbarkeit begrenzen: SSH nicht offen ins Internet stellen, sondern nur über VPN oder feste Adressen erreichbar machen.
7. Zuständigkeit klären: Haltet schriftlich fest, wer welche Images aktuell hält und wie schnell Sicherheitsupdates eingespielt werden.
8. Rhythmus festlegen: Images regelmäßig neu bauen, nicht erst, wenn eine Warnung kommt.

Unsere Einordnung#

„sshole“ ist ein gutes Beispiel dafür, dass Sicherheit im Mittelstand selten an fehlenden Patches scheitert, sondern an fehlendem Überblick. Wer seine Systeme kennt, ist mit dieser Lücke in einer Stunde fertig. Wer sie nicht kennt, hat ein Suchproblem, und das wird mit jeder weiteren KI-Anwendung größer.

Genau damit beginnt unser KI-Readiness-Audit: Wir erfassen, welche Systeme, Container und KI-Tools bei euch laufen, wer sie betreut und wo offene Zugänge bestehen. Bei eigener Software unterstützen wir außerdem mit Custom Software, die von Anfang an mit schlanken, regelmäßig aktualisierten Images und ohne unnötige Zugänge gebaut wird. Wenn ihr wissen wollt, wo ihr steht, meldet euch gern unverbindlich.

Quellen#

• BSI: OpenSSH, Schwachstelle gefährdet Alpine Linux und weitere Produkte (06.11.2026)
• OpenSSH Release Notes, OpenSSH 10.6p2 (05.11.2026)
• AWA Consulting: PHP-Lücken im Shop, erst das Inventar (04.11.2026)