libssh2: Kritische Out-of-Bounds-Lücke gefährdet SSH-Infrastruktur – Patches nur als Commits

Die weitverbreitete Open-Source-Bibliothek libssh2 enthält zwei Sicherheitslücken, die am 17. Juni 2026 öffentlich gemacht wurden. Die kritische Schwachstelle CVE-2026-55200 erlaubt Angreifern das Auslösen eines Heap-Speicherfehlers in der Funktion ssh2_transport_read(). Bei erfolgreicher Ausnutzung ist Code-Ausführung auf dem betroffenen System möglich. Eine zweite Lücke, CVE-2026-55199, ist als hochriskant eingestuft und kann ebenfalls Speicherfehler auslösen. Betroffen sind alle libssh2-Versionen bis einschließlich 1.11.1. Reparierte Patches existieren bislang nur als GitHub-Commits – eine neue Release-Version mit den Fixes steht aus.

Meldung und Einordnung

Am 17. Juni 2026 hat das GitHub-Sicherheitsteam zwei Advisories für die SSH-Client-Bibliothek libssh2 veröffentlicht. Beide Lücken werden über manipulierte SSH-Pakete ausgelöst, die der Bibliothek ein überschrittenes packet_length-Feld unterschieben. Die Spezifikation sieht zwar eine Obergrenze für die Paketlänge vor, die alte Codebasis erzwingt sie an dieser Stelle jedoch nicht zuverlässig. Damit kann ein Angreifer den Heap-Speicher des Zielprozesses korrumpieren und im schlimmstenfall Schadcode mit den Rechten des SSH-Prozesses ausführen. Neben der Code-Ausführung sind zudem Denial-of-Service-Szenarien denkbar, etwa durch gezielte Speicherzugriffsfehler.

libssh2 ist nicht die Bibliothek, die direkt in OpenSSH steckt. Sie kommt vor allem in eingebetteten Anwendungen, eigenen Automatisierungstools, Konfigurations-Management-Clients, Router- und IoT-Firmware sowie in zahlreichen Monitoring- und Sicherheitsagenten zum Einsatz. Damit betrifft die Schwachstelle nicht nur klassische Linux-Server, sondern auch eine breite Klasse von Geräten, die über keinen klassischen Patchkanal der Hersteller aktualisiert werden. Die heise-Meldung vom 21. Juni 2026 weist ausdrücklich darauf hin, dass eine Ausnutzung weitreichende Folgen haben könnte, weil die Bibliothek an sensiblen Netzstellen für die Fernsteürung von Routern, IoT-Geräten und Servern eingesetzt wird.

Technische Details für Admins

Die kritische Lücke CVE-2026-55200 sitzt in ssh2_transport_read(). Diese Funktion liest den nächsten SSH-Transportframe aus dem Socket. Sie überprüft das packet_length-Feld, legt damit die Größe des internen Puffers fest und kopiert anschließend die empfangenen Nutzdaten dorthin. Die Codebasis von libssh2 bis 1.11.1 erzwingt an dieser Stelle keine harte Obergrenze, sondern lediglich ein internes Limit, das per Konfiguration in bestimmten Pfaden umgangen werden kann. Ein Angreifer, der eine SSH-Sitzung initiiert oder eine bestehende Sitzung übernimmt, kann durch präparierte Pakete mit extrem großen packet_length-Werten Heap-Speicher korrumpieren.

Die zweite Lücke CVE-2026-55199 ist nach aktuellem Stand weniger gut dokumentiert, beide Advisories verweisen jedoch auf den gleichen Angriffsvektor. Beide Schwachstellen lassen sich mit den am 17. Juni eingespielten Commits 7acf3df und 1762685 beheben, die sich bereits im Master-Branch befinden. Eine neue Release-Version (vermutlich 1.11.2) ist laut heise noch nicht angekündigt, sodass Admins, die ihre Distribution nicht selbst übersetzen können, derzeit auf das Sicherheitsupdate der Distribution angewiesen sind.

Risiko für KMU und Betrieb

Im KMU-Umfeld laufen SSH-Zugriffe häufig über Distribution-Standardpakete, deren Versionen nur bei einem regulären Sicherheitsupdate aktualisiert werden. Genau diese Automatik ist derzeit die Schwachstelle: Solange Distributionen die reparierte libssh2-Ausgabe nicht in ihre stabilen Repos aufnehmen, bleiben die Systeme verwundbar. Bei Debian wird die reparierte Version 1.11.1-3 nach Angaben von heise derzeit getestet. Bei Kali Linux ist der Fix offenbar bereits seit Mai 2026 enthalten. Für Ubuntu, Red Hat Enterprise Linux, SUSE Linux Enterprise und deren Derivate gibt es zum Zeitpunkt der Meldung noch keine bestätigten Repos.

Besonders kritisch ist die Lage für Embedded-Geräte, Router, NAS-Systeme und IoT-Endpunkte. Diese Geräte verwenden häufig statische libssh2-Versionen in ihrer Firmware und erhalten nur über den Hersteller Sicherheitsupdates. Admins, die in ihrem Netzwerk über Geräte mit libssh2-Abhängigkeiten verfügen, sollten deren Firmware-Stand gezielt prüfen und beim Hersteller nachfragen, ob ein Patch geplant ist. Wer die Bibliothek selbst in eigenen Anwendungen linkt – etwa in Backup-Tools, Konfigurations-Management-Erweiterungen oder Monitoring-Agenten – ist ebenfalls direkt betroffen und muss den Workload neu gegen den aktuellen Master-Branch übersetzen.

Was Admins jetzt prüfen sollten

1. Bestand ermitteln: Auf allen Linux- und Unix-Hosts den installierten libssh2-Stand mit dpkg -l libssh2-1t64, rpm -q libssh2 oder pkg-config --modversion libssh2 prüfen. Werte unter 1.11.1-3 sind aktüll verwundbar.
2. Distribution-Status beobachten: Auf den Sicherheits-Seiten der eigenen Distribution (Debian Security Tracker, Ubuntu Security Notices, RHSA, SUSE-SUSE-Security-Announce) den Status der libssh2-Aktualisierung verfolgen. Kali-Admins können sofort aktualisieren, alle anderen warten auf den offiziellen Roll-out.
3. Eigene Software rebuilds: Wer libssh2 statisch in eigene Anwendungen linkt, sollte kurzfristig den Master-Branch ziehen und neu kompilieren. Dazu genügt git clone https://github.com/libssh2/libssh2.git, dann cmake -B build && cmake --build build.
4. SSH-Zugriffe segmentieren: Wo immer möglich, den SSH-Zugriff auf ein verwaltetes Jump- oder Bastion-Host beschränken. Direkt erreichbare SSH-Ports auf Firewall-Ebene blockieren, Jump-Host-Patch priorisieren.
5. Logging schärfen: Auth-Log auf ungewöhnliche SSH-Verbindungsabbrüche und Speicherfehler-Signale (Segfaults im sshd-Pfad, Kernel-messages zu ssh) prüfen. Werkzeuge wie journalctl -u ssh und ausearch -m avc geben Hinweise auf misslungene Angriffsversuche.
6. Patch-Strategie festlegen: Sobald die reparierte Distribution-Version erscheint, diese zuerst auf internen Testsystemen ausrollen, danach auf nicht-produktiven Systemen und erst im dritten Schritt auf produktiven Hosts – idealerweise im Rahmen eines geplanten Wartungsfensters.

Betriebscheck nach der Meldung

1. Welche Hosts in unserem Netz haben eine libssh2-Version < 1.11.1 installiert? Liste mit Inventardatenbank abgleichen.
2. Werden SSH-Zugriffe ausschließlich über zentrales Bastion-/Jump-Host-Konzept geroutet, sodass wir die Patch-Front reduzieren können?
3. Setzen wir eigene Anwendungen ein, die libssh2 statisch linken? Wenn ja: Ist der Build-Pipeline-Stand aktualisiert?
4. Sind in den Auth-Logs der vergangenen 30 Tage ungewöhnliche SSH-Sitzungsabbrüche oder segfault-Meldungen aufgefallen?
5. Wurden Embedded-Geräte (Router, NAS, Firewalls) im Bestand bereits auf eine libssh2-Version < 1.11.1 überprüft? Gibt es Hersteller-Status zu CVE-2026-55200?
6. Liegt der Distribution-Patch-Status der wichtigsten Linux-Distributionen (Debian, Ubuntu, RHEL, SUSE) im zentralen Patch-Management-Tool vor, sodass ein automatisierter Roll-out starten kann?

Admin-Einschätzung

Die Lücke ist in der Brisanz vergleichbar mit früheren Speicherfehlern in Krypto- und SSH-Bibliotheken. Solange kein Exploit in the Wild beobachtet wird, ist das Risiko überschaubar. Sobald jedoch ein funktionierender Exploit-Code in Metasploit, in Ransomware-Toolkits oder in Bug-Bounty-Listen auftaucht, steigt die Dringlichkeit deutlich. Admins sollten den Vorfall deshalb nicht auf die lange Bank schieben, sondern die wenigen Handlungsschritte jetzt anstoßen: Bestand aufnehmen, Distribution-Status beobachten, eigene Anwendungen rebuilden, SSH-Zugriffe segmentieren. Wer einen zentralen SSH-Bastion-Host betreibt, hat klar weniger Patch-Aufwand.

Strategisch ist die Meldung ein weiterer Beleg, dass Open-Source-Bibliotheken in der Lieferkette einen klaren Patch- und Beobachtungsprozess brauchen. libssh2 wird in vielen Anwendungen transitiv genutzt, ein dist-upgrade allein reicht daher nicht. Wer SBOM-Werkzeuge wie Trivy im CI/CD-Stack nutzt, kann eine verwundbare libssh2-Version transparent ausweisen und seinen Build verlässlich aktualisieren. Empfehlung: trivy image regelmäßig in Build-Pipelines einbinden und die Ergebnisse ins Vulnerability-Management übernehmen.

Passende Anleitungen auf S-EDV

1. SSH-Hardening Deep-Dive: sshd_config, Match-Blöcke und ssh-audit für KMU-Server – wer seinen SSH-Zugriff segmentiert und härter, reduziert die Angriffsfläche gegen Bibliothekslücken.
2. VPS absichern und härten: Anleitung mit UFW, SSH-Keys und Fail2Ban (Hetzner/Netcup) – Schritt-für-Schritt-Aufbau eines abgesicherten Servers, inkl. SSH-Key-Setup.
3. Linux-Server absichern: UFW-Firewall und Fail2ban – Grundlagen-Anleitung, die bei jedem frisch aufgesetzten Server Pflicht ist.
4. Docker-Images auf Schwachstellen scannen mit Trivy: CVE-Check, SBOM und automatisierte CI/CD-Reports – erkennt transitive libssh2-Abhängigkeiten in Container-Images.

Quellen

1. heise online: Sicherheitslücken gefährden Verbindungen über libssh2 (21.06.2026)
2. GitHub Security Advisory GHSA-R8MH-X5QV-7GG2 zu CVE-2026-55200
3. GitHub Security Advisory GHSA-3CFQ-4XX4-RMPG zu CVE-2026-55199
4. libssh2-Commit 7acf3df (Fix für CVE-2026-55200)
5. libssh2-Commit 1762685 (Fix für CVE-2026-55199)
6. Debian Security Tracker: libssh2