Kritische Sicherheitslücken in libssh2: Was IT-Verantwortliche jetzt wissen müssen

Schweregrad: Hoch | Veröffentlicht: 28.07.2026 | Quelle: BSI WID Advisory

Einleitung: Eine Bibliothek, die kaum jemand kennt – und trotzdem überall steckt

Wenn in Ihrem Unternehmen Server miteinander kommunizieren, Automatisierungsskripte laufen oder Entwickler über verschlüsselte Verbindungen auf Remote-Systeme zugreifen, ist die Wahrscheinlichkeit hoch: libssh2 ist beteiligt. Die quelloffene C-Bibliothek implementiert das SSH-2-Protokoll und ist tief in unzähligen Softwareprodukten, Betriebssystem-Paketen und DevOps-Tools eingebettet – oft unsichtbar für den Endanwender.

Das Bundesamt für Sicherheit in der Informationstechnik (BSI) hat am 28. Juli 2026 ein aktualisiertes Advisory mit hohem Schweregrad veröffentlicht. Die Kernaussage: Ein entfernter, anonymer Angreifer kann mehrere Schwachstellen in libssh2 ausnutzen, um vertrauliche Informationen offenzulegen, einen Denial-of-Service (DoS) auszulösen oder im schlimmsten Fall beliebigen Schadcode auszuführen.

Für deutsche Unternehmen – insbesondere solche, die unter die NIS2-Richtlinie fallen – ist das keine abstrakte Bedrohung. Es ist ein konkreter Handlungsauftrag.

Technischer Hintergrund: Was steckt hinter den libssh2-Schwachstellen?

Was ist libssh2?

libssh2 ist eine clientseitige C-Bibliothek, die SSH-2-Verbindungen ermöglicht. Sie wird unter anderem eingesetzt von:

• cURL / libcurl (dem HTTP-Transfer-Allrounder, der in Millionen von Anwendungen steckt)
• PHP (über die SSH2-Extension)
• Ansible, Fabric und weiteren Automatisierungstools
• Zahlreichen Linux-Distributionen wie RHEL, Debian, Ubuntu und SUSE

Die Angriffsvektoren im Überblick

Die vom BSI gemeldeten Schwachstellen ermöglichen drei Angriffsszenarien:

Entscheidend: Der Angreifer muss weder authentifiziert noch im internen Netzwerk sein. Eine Netzwerkverbindung zum betroffenen Dienst reicht aus. Das erhöht die Angriffsfläche massiv, besonders bei nach außen erreichbaren Systemen.

Warum ist die Schwachstelle so gefährlich?

Viele Unternehmen wissen nicht einmal, dass sie libssh2 verwenden. Die Bibliothek wird als transitive Abhängigkeit mitgeliefert – sie steckt in anderen Paketen, ohne dass IT-Teams sie explizit installiert haben. Das macht Patch-Management besonders herausfordernd: Sie können nur patchen, was Sie kennen.

Auswirkungen auf Deutschland und NIS2-Relevanz

Wen betrifft das besonders?

Betroffen sind potenziell alle Unternehmen, die:

• Linux-basierte Server oder Container (Docker, Kubernetes) betreiben
• SSH-basierte Automatisierung nutzen (CI/CD-Pipelines, Ansible, etc.)
• cURL oder libcurl in eigenen Anwendungen einsetzen
• PHP-Webapplikationen mit SSH2-Extension hosten

Das ist in der Praxis ein sehr breites Spektrum – vom mittelständischen Online-Händler bis zum kritischen Infrastrukturdienstleister.

NIS2: Was bedeutet das für Ihre Pflichten?

Seit Inkrafttreten der NIS2-Umsetzung in Deutschland (NIS2UmsuCG) unterliegen Unternehmen aus wesentlichen und wichtigen Sektoren klaren Pflichten. Eine Schwachstelle dieser Schwere löst konkrete Handlungspflichten aus:

1. Risikomanagement (§ 30 BSIG-neu)
Unternehmen müssen technische und organisatorische Maßnahmen ergreifen, um Risiken für die Sicherheit ihrer Netz- und Informationssysteme zu managen. Das schließt Vulnerability Management explizit ein.

2. Meldepflicht bei Sicherheitsvorfällen (§ 32 BSIG-neu)
Wird die Schwachstelle aktiv ausgenutzt und es kommt zu einem Sicherheitsvorfall mit erheblichen Auswirkungen, besteht eine 24-Stunden-Meldepflicht gegenüber dem BSI (Erstmeldung) sowie eine detaillierte Folgemeldung binnen 72 Stunden.

3. Lieferkettensicherheit
NIS2 verpflichtet auch zur Bewertung von Risiken in der Lieferkette. libssh2 als Drittanbieter-Komponente fällt genau in diesen Bereich.

BSI-Empfehlung: Das BSI rät generell, WID-Advisories mit dem Schweregrad „hoch" innerhalb von 72 Stunden zu bewerten und entsprechende Gegenmaßnahmen einzuleiten.

Praktische Schutzmaßnahmen: 6 konkrete Tipps für Ihr Unternehmen

1. Sofortiger Software-Inventar: Wo läuft libssh2?

Bevor Sie patchen können, müssen Sie wissen, wo libssh2 im Einsatz ist. Nutzen Sie:

• Paketmanager-Abfragen: dpkg -l | grep libssh2 (Debian/Ubuntu) oder rpm -qa | grep libssh2 (RHEL/CentOS)
• Software Composition Analysis (SCA)-Tools wie Syft, Trivy oder OWASP Dependency-Check für Container-Images und Anwendungsabhängigkeiten
• Ihr CMDB/Asset-Management-System für eine systemübergreifende Suche

2. Umgehend patchen – Priorisierung nach Exposition

Spielen Sie verfügbare Sicherheitsupdates so schnell wie möglich ein. Priorisieren Sie dabei:

• Priorität 1: Extern erreichbare Systeme (DMZ, öffentliche APIs, Webserver)
• Priorität 2: Interne CI/CD-Systeme und Automatisierungsinfrastruktur
• Priorität 3: Entwickler-Workstations und interne Tooling-Server

Nutzen Sie die Update-Mechanismen Ihrer Linux-Distribution (apt upgrade, dnf update) oder aktualisieren Sie betroffene Software-Pakete auf die gepatchten Versionen gemäß den Herstellerhinweisen.

3. Netzwerksegmentierung als Schutzschicht

Systeme, die libssh2 nutzen, sollten nicht direkt aus dem Internet erreichbar sein, wenn es nicht zwingend notwendig ist. Prüfen Sie:

• Sind SSH-Ports (22) unnötig nach außen geöffnet?
• Können SSH-Verbindungen auf bekannte IP-Bereiche eingeschränkt werden (IP-Whitelisting)?
• Ist eine Jump-Host / Bastion-Host-Architektur implementiert?

4. Monitoring und Anomalieerkennung aktivieren

Richten Sie Alerting für verdächtige SSH-Verbindungsversuche ein. Konkrete Indikatoren:

• Ungewöhnlich viele fehlgeschlagene SSH-Handshakes (möglicher Exploit-Versuch)
• Verbindungen von unbekannten IP-Adressen zu SSH-Diensten
• Prozesse, die nach SSH-Verbindungsaufbau unerwartete Systemaufrufe ausführen

Integrieren Sie diese Logquellen in Ihr SIEM (z. B. Splunk, Elastic, Microsoft Sentinel).

5. Container-Images und CI/CD-Pipelines überprüfen

In modernen DevOps-Umgebungen ist libssh2 häufig in Basis-Images enthalten. Scannen Sie:

• Alle Docker/OCI-Images in Ihrer Registry mit Tools wie Trivy oder Grype
• Artefakte in Ihrer CI/CD-Pipeline auf verwundbare Bibliotheken
• Stellen Sie sicher, dass Ihre Build-Prozesse immer aktuelle Basis-Images verwenden (kein "frozen" base image ohne Patch-Zyklus)

6. Vorfallsreaktionsplan aktualisieren

Stellen Sie sicher, dass Ihr Team für den Fall einer aktiven Ausnutzung vorbereitet ist:

• Ist der Meldeprozess zum BSI (über das Meldeportal MELDEPLATTFORM des BSI) bekannt und dokumentiert?
• Gibt es einen definierten Eskalationsweg zu Geschäftsführung und Datenschutzbeauftragtem?
• Wurde der Incident Response Plan auf NIS2-Anforderungen aktualisiert?

Fazit: Unsichtbare Abhängigkeiten, sichtbare Konsequenzen

Die libssh2-Schwachstellen sind ein Paradebeispiel für ein wachsendes Problem moderner IT: Die größten Risiken stecken oft nicht in der selbst entwickelten Software, sondern in den unsichtbaren Abhängigkeiten darunter. Eine Bibliothek, die kein Entwickler bewusst "ausgewählt" hat, kann zum Einfallstor für Angreifer werden – und im schlimmsten Fall zu Datenverlust, Systemausfall oder einer NIS2-Meldepflicht führen.

Die gute Nachricht: Wer strukturiert vorgeht, kann das Risiko signifikant reduzieren. Inventarisierung, schnelles Patchen, Netzwerksegmentierung und aktives Monitoring sind keine Hexerei – sie erfordern aber Prozesse, Werkzeuge und Verantwortlichkeiten, die klar definiert sein müssen.

💡 Handlungsempfehlung für IT-Verantwortliche

Vorfälle wie dieser zeigen, wie wichtig ein zentrales NIS2-Compliance-Management ist. Moderne Compliance-Plattformen helfen Ihnen dabei, Schwachstellen-Advisories wie dieses automatisch mit Ihrem Asset-Inventar abzugleichen, Maßnahmen zu priorisieren, Nachweise zu dokumentieren und im Ernstfall Meldeprozesse strukturiert abzuwickeln. Wenn Sie noch kein dediziertes Tool im Einsatz haben, lohnt sich eine Evaluierung – spätestens dann, wenn das BSI klopft.