Veröffentlicht am 05.07.2026
Ein präparierter SSH-Server, der Ihren eigenen Backup-Job, Ihr Git-Deployment oder Ihr PHP-Skript übernimmt – ohne dass jemand ein Passwort eingeben oder auf etwas klicken muss. Genau dieses Szenario ermöglicht CVE-2026-55200, eine kritische Sicherheitslücke in der weit verbreiteten SSH-Client-Bibliothek libssh2. Seit Ende Juni 2026 ist ein öffentlicher Proof-of-Concept-Exploit (ein Machbarkeitsnachweis, der zeigt, dass die Lücke praktisch ausnutzbar ist) im Umlauf. Die Schwachstelle erreicht einen CVSS-Score von 9,2 (nach CVSS 4.0) beziehungsweise 9,8 (nach CVSS 3.1) – und ein offizielles gepatchtes Release steht zum Zeitpunkt dieses Artikels (5. Juli 2026) noch aus.
Das Tückische: libssh2 steckt in unzähligen Programmen, die täglich im Einsatz sind – in curl, Git, PHP, Backup-Tools, Firmware-Updatern und IoT-Geräten. Laut dem Sicherheitsportal Cybernews ist die Bibliothek „möglicherweise in Millionen von Systemen weltweit eingebettet“. In diesem Artikel erklären wir, was passiert ist, wie Sie herausfinden, ob Sie betroffen sind, und was Sie jetzt konkret tun müssen.
libssh2 ist eine Programmbibliothek, mit der Software SSH-Verbindungen aufbauen kann – also verschlüsselte Verbindungen zu anderen Servern, etwa für sicheren Dateitransfer (SFTP) oder das Kopieren von Dateien (SCP). Wichtig zu verstehen: Betroffen ist hier die Client-Seite, also das Programm, das eine Verbindung zu einem Server aufbaut. Der Angriff kommt vom Server – nicht wie üblich vom Client.
Der Sicherheitsforscher Tristan Madani (@TristanInSec) entdeckte einen Fehler in der Funktion ssh2_transport_read() in der Datei transport.c. Diese Funktion verarbeitet eingehende SSH-Pakete während des Verbindungsaufbaus (Handshake). Ein bösartiger oder gekaperter SSH-Server kann ein manipuliertes Paket senden, das den Speicher des verbindenden Clients überschreibt und dazu führt, dass beliebiger Schadcode auf dem Client-System ausgeführt wird – ohne Zugangsdaten und ohne Nutzerinteraktion.
Der zeitliche Ablauf: Der Patch wurde am 12. Juni 2026 über Pull Request #2052 in den libssh2-Quellcode eingepflegt. Die CVE-Vergabestelle VulnCheck veröffentlichte die Schwachstelle am 17. Juni 2026. Heise Online berichtete erstmals am 21. Juni, das NHS England Digital warnte am 23. Juni. Der öffentliche PoC-Exploit tauchte kurz darauf im GitHub-Repository „exploitarium“ auf; The Hacker News und Heise berichteten am 29. Juni darüber.
Im Kern handelt es sich um einen Integer-Overflow, der zu einem Buffer-Overflow führt (Fehlerklasse CWE-680). Das klingt kompliziert, ist aber im Grunde ein Rechenfehler mit fatalen Folgen.
Jedes SSH-Paket enthält ein Feld namens packet_length, das angibt, wie groß das Paket ist. Diesen Wert kontrolliert der Server – und damit ein Angreifer. Der verwundbare Code prüfte zwar, ob der Wert zu klein ist (kleiner als 1), aber er prüfte nicht, ob er zu groß ist. Es fehlte also eine Obergrenze.
Ein Angreifer sendet nun ein Paket mit einem extrem großen Längenwert, etwa 0xffffffff (das entspricht rund 4,29 Milliarden). libssh2 rechnet zu diesem Wert einige kleine Konstanten hinzu, um zu bestimmen, wie viel Speicher es reservieren muss. Weil diese Berechnung mit 32-Bit-Arithmetik erfolgt, „kippt“ die Zahl bei diesem riesigen Ausgangswert um – ein sogenannter Überlauf – und das Ergebnis ist plötzlich winzig. libssh2 reserviert daraufhin einen viel zu kleinen Speicherbereich (Heap-Puffer). Anschließend schreibt der nachfolgende Code aber die volle, überdimensionierte Datenmenge in diesen zu kleinen Bereich. Das Ergebnis ist ein Out-of-Bounds-Heap-Write – Daten werden also über die Grenzen des reservierten Speichers hinaus geschrieben. Über diesen Weg lässt sich die Kontrolle über sogenannte Callback-Pointer und damit letztlich die Ausführung von Schadcode erlangen.
Die Angriffsvoraussetzungen sind aus Sicht eines Angreifers ideal: netzwerkbasiert, geringe Komplexität, keine Privilegien und keine Nutzerinteraktion nötig. Einzige Bedingung: Der Angreifer muss einen bösartigen SSH-Server betreiben oder sich als „Mann in der Mitte“ (Man-in-the-Middle) in die Verbindung einklinken.
Bemerkenswert ist: libssh2 ist schon einmal über nahezu denselben Fehler gestolpert. The Hacker News schreibt dazu:
„libssh2 ist hier schon einmal gestolpert. 2019 wurde Version 1.8.1 ausgeliefert, um eine Reihe von neun Fehlern zu beheben – angeführt von CVE-2019-3855, einem nahezu identischen Integer-Overflow im selben Transport-Read-Code, der es ebenfalls einem bösartigen Server erlaubte, Code auf einem verbindenden Client auszuführen. Sieben Jahre später ist dieselbe Fehlerklasse im selben Code zurück.“ – Swati Khandelwal, The Hacker News, 29. Juni 2026
Der neue Fix (Commit 97acf3d) fügt nun eine strikte Prüfung ein, die jeden packet_length-Wert oberhalb des erlaubten Maximums (LIBSSH2_PACKET_MAXPAYLOAD) ablehnt, bevor gerechnet wird. Gleichzeitig wurden zwei weitere Lücken behoben: CVE-2026-55199 (CVSS 8,2, Denial-of-Service durch CPU-Erschöpfung) und CVE-2025-15661 (CVSS 8,3, ein SFTP-Speicherlesefehler).
Betroffen sind alle libssh2-Versionen bis einschließlich 1.11.1, sofern sie den Patch-Commit 97acf3d nicht enthalten. Weil libssh2 in so vielen Produkten steckt, ist die Angriffsfläche riesig. Arctic Wolf Labs fasst das Risiko so zusammen:
„Diese Klasse von Pre-Auth-Client-Schwachstellen stellt ein branchenübergreifendes, weit verbreitetes Risiko dar – von Server-Infrastruktur über CI/CD-Pipelines, Entwicklerrechner, Backup- und Automatisierungssysteme bis hin zu eingebetteten und IoT-Geräten. Entscheidend: Viele betroffene Anwendungen (curl, Git-GUI-Clients, PHP-SFTP) binden libssh2 oft statisch ein oder betten es ein, was die Erkennung und das Patchen nicht trivial macht.“ – Arctic Wolf Labs, Security Bulletin, 30. Juni 2026
Genau hier liegt das größte Problem für KMU: Viele Programme binden libssh2 statisch ein – die Bibliothek ist also fest in das Programm einkompiliert. ClawNews bringt es auf den Punkt: „Heikel ist die Verbreitung. Viele Programme binden libssh2 statisch ein. Ein Update über den Paketmanager erreicht diese Kopien nicht.“ Ein normales System-Update genügt bei diesen Kopien also nicht.
Für deutsche KMU ist die Lücke besonders relevant, wenn:
Ein konkretes Beispiel für das Patch-Problem unter Windows nennt Heise Online:
„Unter Windows wird dies jedoch schwieriger. Die offiziellen curl-Binärdateien für Windows 8.21.0_2 vom 24. Juni 2026 sind beispielsweise noch statisch mit libssh2 1.11.1 verlinkt, das die Sicherheitslücke aufweist.“ – Dirk Knop, Heise Online, 29. Juni 2026
dpkg -l libssh2-1 (Debian/Ubuntu) oder rpm -q libssh2 (RHEL/CentOS/Fedora) aus. Ist die Version 1.11.1 oder älter und enthält sie nicht den Patch-Commit 97acf3d, ist das System betroffen.ldconfig -p | grep libssh2 zeigt alle im System registrierten libssh2-Bibliotheken.strings /usr/bin/curl | grep libssh2 prüfen Sie, ob curl eine statisch eingebundene Version enthält. Weitere Suche: grep -r libssh2 /usr/lib /usr/local/lib /opt 2>/dev/null.curl --version ausführen. Erscheint libssh2/1.11.1 ohne Patch-Hinweis, ist die Installation betroffen.php -i | grep -i ssh2 zeigt, ob PHP mit der ssh2-Erweiterung kompiliert wurde – dann ist libssh2 eingebunden.trivy image <image-name> oder grype dir:..Da ein offizielles gepatchtes libssh2-Release noch aussteht (der Fix liegt bislang nur als Quellcode-Commit vor), sind vorbeugende Schutzmaßnahmen aktuell besonders wichtig. Debian hat einen zurückportierten Patch in „Testing“ (1.11.1-3 bzw. 1.11.1-4), Kali Linux enthält den Fix bereits seit Mai 2026. Ubuntu, Fedora, SUSE und Red Hat arbeiten an Backports. Für Windows-Binärdateien gibt es noch kein Update.
StrictHostKeyChecking=yes) und keine unbekannten Server akzeptieren. Das erschwert Man-in-the-Middle-Angriffe.apt-get update && apt-get upgrade libssh2-1 (Debian/Ubuntu) bzw. dnf update libssh2 (RHEL/Fedora).Zum aktuellen Zeitpunkt (5. Juli 2026) hat die US-Behörde CISA keine aktive Ausnutzung in freier Wildbahn bestätigt. Der öffentliche PoC bestätigt zwar die technische Ausnutzbarkeit, ist aber kein schlüsselfertiger Remote-Exploit für beliebige Produktivsysteme – er enthält einen C11-Verifier, einen minimalen bösartigen Python-SSH-Server und einen kontrollierten lokalen RCE-Harness. The Hacker News formuliert die offenen Fragen treffend:
„Die offenen Fragen sind, wie schnell jemand den lokalen Harness in einen zuverlässigen Remote-Exploit verwandelt, und wie viele gebündelte Kopien verwundbar bleiben, weil sich niemand daran erinnert, dass libssh2 darin ausgeliefert wurde.“ – The Hacker News, 29. Juni 2026
Der EPSS-Wert (ein Schätzwert für die Ausnutzungswahrscheinlichkeit) liegt laut GitHub Advisory Database bei 0,732 % (50. Perzentil) – moderat, aber steigend. Insgesamt ist das Risiko für KMU trotz fehlender bestätigter Angriffe als hoch einzustufen: Der hohe CVSS-Score, der öffentliche PoC, die fehlende offizielle gepatchte Version und die extrem weite Verbreitung von libssh2 ergeben zusammen ein erhebliches Angriffspotenzial.
Für deutsche KMU wird die Lücke datenschutzrechtlich vor allem dann relevant, wenn sie ausgenutzt wird und dabei personenbezogene Daten kompromittiert werden – etwa bei der Übernahme eines Servers, der Kundendaten verarbeitet. Dann liegt eine Verletzung des Schutzes personenbezogener Daten im Sinne von Art. 4 Nr. 12 DSGVO vor.
Nach Art. 33 DSGVO muss der Verantwortliche eine solche Verletzung unverzüglich und möglichst binnen 72 Stunden der zuständigen Datenschutzaufsichtsbehörde melden (je nach Bundesland etwa dem BayLDA oder der LfDI Baden-Württemberg). Besteht ein hohes Risiko für die Betroffenen, kann nach Art. 34 DSGVO zusätzlich eine Benachrichtigungspflicht gegenüber diesen Personen bestehen.
Wichtig auch: Art. 32 DSGVO verpflichtet Verantwortliche zu geeigneten technischen und organisatorischen Maßnahmen – dazu gehört das Einspielen verfügbarer Sicherheits-Updates. Das Unterlassen von Patches kann als Verstoß gewertet werden. Dass verspätete Meldungen teuer werden können, zeigt ein Fall aus Griechenland: Die dortige Datenschutzbehörde HDPA verhängte im Dezember 2023 ein Bußgeld von 50.000 Euro allein für die nicht fristgerechte Meldung einer Datenpanne (Alpha Bank).
Praktisch bedeutet das für KMU: (1) Prüfen, ob libssh2 im Einsatz ist; (2) sofortige Schutzmaßnahmen ergreifen; (3) die Risikoanalyse und ergriffenen Maßnahmen gemäß Art. 33 Abs. 5 DSGVO dokumentieren; (4) im Schadensfall unverzüglich melden.
CVE-2026-55200 ist eine der Schwachstellen, die man leicht übersieht – gerade weil libssh2 selten direkt sichtbar ist, sondern tief in anderen Programmen steckt. Genau das macht sie gefährlich: Ein Update über den Paketmanager reicht nicht, wenn curl, ein Backup-Agent oder ein IoT-Gerät die Bibliothek statisch eingebaut hat. Auch wenn bislang keine aktive Ausnutzung bestätigt ist und ein offizielles Release noch aussteht, ist Handeln geboten.
Die wichtigsten Schritte sind unabhängig vom Patch-Status sofort umsetzbar: ausgehende SSH-Verbindungen auf vertrauenswürdige Ziele beschränken, Host-Keys strikt verifizieren und ein vollständiges Inventar aller libssh2-Nutzungen erstellen. Wer diese drei Punkte jetzt angeht, verschafft sich Zeit, bis die gepatchten Versionen für alle Plattformen bereitstehen – und schließt die gefährlichste Lücke: die, von der man nicht weiß, dass sie existiert.