Grafana Labs ist Opfer einer Cyberattacke geworden. Dabei hatten Angreifer Zugriff auf den Sourcecode von Grafana. Die Entwickler wollen sich aber nicht auf eine Zahlung des geforderten Lösegelds einlassen.

Grafana ist eine Open-Source-Anwendung für die Analyse, das Monitoring und die Visualisierung von Echtzeitdaten aus verschiedenen Quellen in IT-Umgebungen. Das Tool wird weltweit unter anderem auch von großen Unternehmen aus der Fortune-50-Rangliste genutzt.

Die Attacke

Über den Vorfall berichtet Grafana Labs auf X. Der Stellungnahme zufolge konnten sich die Angreifer von CoinbaseCartel mittels geklauter Zugangsdaten Zugriff auf die GitHub-Umgebung des Tools verschaffen und dort auf Daten zugreifen. Wie die Angreifer in den Besitz des GitHub-Tokens gekommen sind, führt Grafana Labs derzeit nicht aus. Sie geben an, die Quelle intern zu kennen und die Zugangsdaten mittlerweile widerrufen zu haben. Zusätzlich habe man weitere Sicherheitsmaßnahmen ergriffen.

Die Entwickler versichern, dass nach jetzigem Kenntnisstand keine Kundendaten oder persönliche Daten von Mitarbeitern von dem Vorfall betroffen sind. Grafana Labs gibt an, kein Lösegeld zu zahlen. Damit folgen sie der offiziellen Empfehlung des FBIs. Schließlich ist mit einer Zahlung nicht garantiert, dass die Kriminellen die Daten „zurückgeben“. Außerdem habe es eine Vorbildfunktion für andere Unternehmen, die Opfer solcher Cyberattacken sind, wenn man das Lösegeld nicht zahlt und den Kriminellen somit kein Geld in den Rachen wirft.

Wenn die Untersuchung der IT-Systeme abgeschlossen ist, wollen die Grafana-Entwickler weitere Details zu dem Vorfall veröffentlichen. Wann das so weit ist, ist zurzeit noch unklar.

(des)

Das Admin-Tool für Unix-Server Webmin ist verwundbar. Angreifer können unter anderem die Zwei-Faktor-Authentifizierung (2FA) umgehen. Es sind aber auch root-Attacken denkbar. Reparierte Versionen stehen zum Download bereit.

Unbefugte Zugriffe

Für die 2FA-Lücke (CVE-2026-42210) steht eine Einstufung des Bedrohungsgrads offensichtlich noch aus. Das Notfallteam CERT Bund vom BSI stuft die Gefahr in einem Beitrag insgesamt als „kritisch“ ein.

Im Sicherheitsbereich der Webmin-Website führen die Entwickler aus, dass Angreifer über die Basic-HTTP-Authentifizierung 2FA umgehen können. Für eine erfolgreiche Attacke müssen Angreifer aber Nutzernamen und Passwort kennen. In diesem Fall fällt nur der Einmalcode der 2FA weg.

Die root-Lücke steckt den Entwicklern zufolge in den integrierten Hilfeseiten des Tools. Wie ein derartiger Angriff im Detail ablaufen könnte, ist bislang unklar. Klappt eine Attacke, sollen Angreifer als root-Nutzer auf Instanzen zugreifen können. In so einer Position ist davon auszugehen, dass Angreifer die volle Kontrolle über Systeme erlangen. Weil mit dem Tool Server aus der Ferne verwaltet werden, kann eine solche Attacke weitreichende Folgen haben.

Die dritte nun geschlossene Schwachstelle betrifft das Squid-Modul. An dieser Stelle sind im Kontext des installierten Squid-Cachemanagers ebenfalls root-Attacken vorstellbar. Auch hier ist derzeit nicht bekannt, wie ein Angriff ablaufen könnte. Bislang gibt es seitens der Entwickler keine Berichte, dass Angreifer die Sicherheitslücken bereits ausnutzen

Update installieren

Admins sollten sicherstellen, dass sie mindestens die mit Sicherheitspatches ausgestattete Webmin-Ausgabe 2.640 installiert haben. Derzeit ist die Version 2.641 aktuell.

Die Version Webmin 2.600 aus dem vergangenen November hatte eine komplett überarbeitete Bedienoberfläche mitgebracht.

(des)

Im ngx_http_rewrite_module von NGINX Open Source und NGINX Plus ermöglicht eine Schwachstelle nicht authentifizierten Angreifern aus dem Netz, die Server lahmzulegen. In Sonderfällen könnten sie sogar Schadcode einschleusen und ausführen. Erste Angriffe wurden bereits beobachtet.

Eine Sicherheitsmeldung von F5 erörtert die Sicherheitslücke. Die Schwachstelle im Rewrite-Modul lässt sich missbrauchen, wenn einer Rewrite-Direktive eine rewrite-, if– oder set-Direktive und eine Perl-kompatible Regular Expression folgt, die Ersetzung mit einem Ausdruck mit einem „?“ darin vornimmt. Dann können Angreifer aus dem Netz ohne vorherige Anmeldung mit manipulierten Paketen einen Heap-basierten Pufferüberlauf im NGINX-Worker-Prozess auslösen, der zu einem Neustart führt (Denial of Service, DoS). In dem unwahrscheinlichen Fall, dass die Address Space Layout Randomization (ASLR) deaktiviert ist, kann das sogar zur Ausführung von eingeschleustem Code führen (CVE-2026-42945, CVSS 8.1, Risiko „hoch“; CVSS4 9.2, Risiko „kritisch“). Die modernere Schwachstellenbewertung kommt zu einer höheren Risikoeinschätzung.

Die Lücke ist gut abgehangen, der verantwortliche Programmcode hat die Volljährigkeitsgrenze überschritten: 18 Jahre hat er auf dem Buckel. Ein Proof-of-Concept-Exploit (PoC) demonstriert den Missbrauch der „NGINX Rift“-Schwachstelle. VulnCheck gibt auf LinkedIn an, inzwischen aktiven Missbrauch der Sicherheitslücke in freier Wildbahn beobachtet zu haben. Im Regelfall führt das zu einem DoS gegen verwundbare Server, von denen laut VulnCheck 5,7 Millionen im Internet erreichbar sind.

Weitere Sicherheitslücken in NGINX OSS und Plus

In NGINX OSS und Plus sind noch weitere Schwachstellen entdeckt worden, die jedoch eine deutlich geringere Risikoeinschätzung aufweisen. Im HTTP/3-QUIC-Modul gibt es eine Spoofing-Lücke (CVE-2026-40460, CVSS 6.5, Risiko „mittel“). ngx_http_scgi_module und ngx_http_uwsgi_module können exzessiv Speicher belegen oder Daten preisgeben (CVE-2026-42946, CVSS 6.5, Risiko „mittel“). Weitere Schwachstellen betreffen den HTTP/2-Proxy-Modus (CVE-2026-42926, CVSS 5.8, Risiko „mittel“), das ngx_http_charset_module (CVE-2026-42934, CVSS 4.8, Risiko „mittel“) und das ngx_http_ssl_module (CVE-2026-40701, CVSS 4.8, Risiko „mittel“).

Nicht alle Lücken betreffen alle NGINX-OSS- und -Plus-Versionen, jedoch sind die jüngsten Fassungen mit Korrekturen für die jeweils enthaltenen Schwachstellen ausgerüstet. F5 nennt die Versionen NGINX Plus 37.0.0, R36 P4 und R32 P6, NGINX Open Source 1.31.0 und 1.30.1 (0.xer-Versionen erhalten keinen Fix) und weitere, die die sicherheitsrelevanten Fehler ausbessern. Für mehrere Lösungen hat F5 jedoch noch keine Fixes zur Hand, beispielsweise NGINX Instance Manager, NGINX App Protect WAF und weiteren. Insbesondere für die bereits attackierte Sicherheitslücke nennt F5 in der Mitteilung aber auch Anpassungen für Rewrite-Regeln, die die Schwachstellen nicht aufweisen.

Zuletzt fielen eher Sicherheitslücken im Web-Interface Nginx UI auf. Die haben Angreifern etwa ermöglicht, ganze Instanzen zu übernehmen.

(dmk)