Die Open-Source-SSH-Bibliothek libssh2 ist verwundbar. Angreifer können an zwei Sicherheitslücken ansetzen, um Systeme zu attackieren. Im schlimmsten Fall kann Schadcode Computer kompromittieren. Der Patchstatus ist den derzeit verfügbaren Informationen zufolge undurchsichtig. Zum Zeitpunkt dieser Meldung gibt es keine Berichte, dass Angreifer die Schwachstellen bereits ausnutzen.

Unternehmen setzen die Bibliothek an empfindlichen Stellen im Netzwerk ein, um etwa Router und IoT-Feräte fernzusteuern und Server zu managen. Demzufolge könnten erfolgreiche Attacken weitreichende Folgen haben.

Warten auf reparierte Ausgabe

Beide Lücken (CVE-2026-55200 „kritisch“, CVE-2026-55199 „hoch“) sind auf GitHub dokumentiert. Angreifer können über präparierte SSH-Pakete Speicherfehler auslösen und Schadcode ausführen. Außerdem sind DoS-Attacken vorstellbar.

Davon sind den Entwicklern zufolge alle libssh2-Versionen bis einschließlich 1.11.1 bedroht. Das Problem ist, dass beide Sicherheitspatches derzeit nur in Form von GitHub-Commits (7acf3df, 1762685) existieren. Offensichtlich sind die Fixes bereits im Master-Branch verfügbar, aber eine neue Version steht noch aus. Stichproben bei Linux-Distributoren haben Folgendes ergeben: Laut dem Debian Security Tracker wird die reparierte Ausgabe 1.11.1-3 derzeit getestet. In Kali Linux ist diese Version wohl schon seit Mai dieses Jahres enthalten.

(des)

Derzeit haben es Angreifer auf WordPress-Websites mit Gravity-SMTP-Plug-in abgesehen und attackieren Instanzen. Ein Sicherheitspatch ist bereits seit Ende dieses Jahres verfügbar, aber offensichtlich noch nicht flächendeckend installiert.

Vor den Attacken warnen Sicherheitsforscher von Wordfence in einem Beitrag. Ihnen zufolge ist die Lücke (CVE-2026-4020 „mittel“) seit März dieses Jahres bekannt. Seitdem gibt es auch die reparierte Ausgabe 2.1.5. Alle vorigen Versionen sind verwundbar.

Die Forscher geben an, dass das Plug-in derzeit rund 100.000 aktive Installationen aufweist.

Unbefugte Zugriffe

Ansatzpunkt für Angreifer ist ein nicht ausreichend sicher konfigurierter REST-API-Endpoint. So können sie ohne Authentifizierung darauf zugreifen, um über einen HTTP-GET-Request detaillierte Systemkonfigurationen abzurufen und diese Informationen für weiterführende Attacken zu nutzen.⁣

Die Sicherheitsforscher geben an, bereits 17 Millionen Angriffsversuche dokumentiert zu haben. Admins sollten dementsprechend zügig handeln und ihre Instanzen absichern. In ihrem Beitrag führen sie detaillierte Informationen zur Lücke auf. Zusätzlich finden Admins dort konkrete Hinweise (Indicators of Compromise, IoC), wie IP-Adressen, an denen sie bereits attackierte Systeme erkennen können.

(des)

Admins von Atlassian-Anwendungen sollten, um möglichen Attacken vorzubeugen, die ab sofort verfügbaren Sicherheitsupdates für verschiedene Produkte des Softwareherstellers installieren. Geschieht das nicht, können Angreifer Sicherheitslücken in etwa Bitbucket, Confluence und Jira Service Management ansetzen. Bislang gibt es keine Berichte, dass Angreifer die Schwachstellen bereits ausnutzen.

Überblick für Admins

Wie aus dem Sicherheitsbereich der Atlassian-Website hervorgeht, haben die Entwickler in aktuellen Versionen insgesamt 100 Lücken geschlossen. Davon sind neben dem eigenen Code auch Abhängigkeiten zu etwa Apache Tomcat betroffen.

Weil eine Auflistung der Schwachstellen und reparierten Ausgaben den Rahmen dieser Meldung sprengt, müssen sich Admins auf der verlinkten Seite des Softwareherstellers einen Überblick verschaffen. Im Folgenden finden sich einige besonders bedrohliche Lücken.

Die Gefahren

Unter den geschlossenen Schwachstellen sind auch einige „kritische“ Lücken – darunter sogar welche mit maximalem CVSS Score 10 von 10 (etwa CVE2026-40175). Das ist zum Beispiel der Fall in Axios im Zusammenhang von Jira Data Center and Server. Die Atlassian-Entwickler schreiben, dass aufgrund der Form der Abhängigkeit in diesem Kontext eine weniger bedrohliche Einstufung als kritisch gilt. Bei dieser Prototype-Pollution-Schwachstelle können Angreifer manipulierend eingreifen und etwa eigenen Code ausführen. Dagegen sollen die Versionen 11.3.7 (LTS) recommended Data Center Only und 10.3.22 (LTS) Data Center Only gerüstet sein.

Der Großteil der verbleibenden Lücken ist mit dem Bedrohungsgrad „hoch“ eingestuft. An diesen Stellen können Angreifer unter anderem für DoS-Attacken (etwa CVE-2026-33388) ansetzen oder sogar Schadcode aus der Ferne ausführen (CVE-2026-41044).

(des)