Eigene Forschung

CVE-2026-15583: SSRF im Grafana MCP Server erklärt

Von Lucas Weber, CyberSec42 · Stand 28.10.2026

CVE-2026-15583 ist eine Server-Side Request Forgery (SSRF) nach dem Muster „Confused Deputy“ im Open-Source-Projekt Grafana MCP Server (mcp-grafana): Über den Request-Header X-Grafana-URL konnte ein Aufrufer ohne Anmeldung festlegen, an welchen Host der Server seine in der Umgebung hinterlegten Grafana-Zugangsdaten schickt. Der CVE-Eintrag bewertet die Schwachstelle mit CVSS 8.6 (hoch) und führt alle Versionen bis einschließlich 0.17.1 als betroffen. Behoben ist sie in Version 0.17.2 vom 13.07.2026, als Finder nennt der CVE-Eintrag CyberSec42.

Die Fakten auf einen Blick

Hintergrund: Was ein MCP-Server ist und warum er Zugangsdaten hält

Das Model Context Protocol (MCP) ist ein offener Standard, über den KI-Assistenten Werkzeuge und Datenquellen ansprechen. Ein MCP-Server sitzt dazwischen: Er nimmt die Werkzeugaufrufe eines KI-Clients entgegen und übersetzt sie in Aufrufe an ein Zielsystem. Der Grafana MCP Server gibt laut seiner Dokumentation KI-Assistenten Zugriff auf eine Grafana-Instanz. Damit lassen sich Metriken und Logs abfragen, Dashboards suchen und verwalten, Alert-Regeln pflegen und Funktionen wie Grafana Incident und Sift nutzen.

Für all das braucht der Server Zugangsdaten zu Grafana. Üblicherweise trägt der Betreiber die Adresse der Instanz und einen Service-Account-Token in Umgebungsvariablen ein (GRAFANA_URL und GRAFANA_SERVICE_ACCOUNT_TOKEN, früher GRAFANA_API_KEY). Ab dann handelt der Server mit den Rechten dieses Tokens, und zwar für jeden, der ihn ansprechen kann. Genau deshalb ist ein MCP-Server ein lohnendes Ziel: Er ist ein Stellvertreter mit Befugnissen. Grundsätzliches zur Absicherung solcher Server steht in unserem Leitfaden zu MCP-Servern; hier geht es um den konkreten Fall.

Wichtig für das Verständnis ist die Betriebsart, im MCP-Jargon der Transport. Der Grafana MCP Server kennt drei: stdio (der Standard, der KI-Client startet den Server als lokalen Prozess), sse und streamable-http (der Server läuft als Netzwerkdienst und nimmt HTTP-Anfragen an). Bei den HTTP-Transporten kann der Server Konfiguration zusätzlich pro Anfrage aus Headern lesen, darunter X-Grafana-URL für die Zieladresse und eigene Header für einen Token. Laut Quellcode ist das für Szenarien mit mehreren Grafana-Instanzen gedacht, eine nützliche Funktion. Die Schwachstelle lag im Zusammenspiel dieser Header mit den Zugangsdaten aus der Umgebung.

Die Schwachstelle

In einfachen Worten

Stellen Sie sich einen Kurier vor, der mit Ihrem Firmenausweis Unterlagen bei Ihrer Hausbank abholt. Jeder Auftraggeber darf ihm eine andere Adresse nennen, falls die Bank einmal mehrere Filialen hat. Der Kurier prüft aber nicht, ob die neue Adresse noch zu Ihrer Bank gehört, und zeigt den Firmenausweis an jeder Tür vor. Wer ihm die Adresse eines eigenen Büros nennt, bekommt Ihren Ausweis zu sehen und kann ihn kopieren.

So verhielt sich der Grafana MCP Server bis Version 0.17.1. Der Ausweis ist der Service-Account-Token, die Adresse ist der Header X-Grafana-URL.

Technisch

Der Server ermittelte die Zieladresse und die Zugangsdaten unabhängig voneinander, und für beides gab es einen eigenen Rückfall auf die Umgebung. So beschreibt es auch die Nachricht des Fix-Commits. Kam eine Anfrage mit X-Grafana-URL, aber ohne eigenen Token-Header, übernahm der Server die Adresse aus dem Header und den Token aus der Umgebung. Dasselbe galt für Basic-Auth und für zusätzliche Header, die der Betreiber per Umgebung konfiguriert hatte. Solche Header können selbst Geheimnisse tragen, etwa einen Authorization-Header. Der anschließende Aufruf an „Grafana“ ging damit samt Zugangsdaten des Betreibers an einen Host, den der Aufrufer bestimmt hatte.

Der Begriff Confused Deputy beschreibt genau diese Lage: Ein Dienst mit Befugnissen (der Stellvertreter) wird von jemandem ohne diese Befugnisse dazu gebracht, sie für fremde Zwecke einzusetzen. Der CVE-Eintrag hält außerdem fest, dass derselbe Mechanismus SSRF gegen beliebige interne Dienste ermöglicht, einschließlich Cloud-Metadaten-Endpunkten. Die Grafana-Advisory spricht von „credentialed SSRF“, also Anfragen an interne Ziele, die zusätzlich Zugangsdaten mitführen.

Zur Einordnung des Vektors: PR:N und UI:N bedeuten, dass weder eine Anmeldung noch eine Handlung eines Nutzers nötig war. S:C (Scope changed) bedeutet nach der CVSS-Spezifikation, dass die Auswirkung über die verwundbare Komponente hinausreicht. Verwundbar war der MCP-Server, betroffen ist die Grafana-Instanz, deren Token abfließen konnte. C:H steht für den Verlust der Vertraulichkeit, Integrität und Verfügbarkeit des Servers selbst sind laut Vektor nicht betroffen. Wir haben den Basiswert von 8.6 anhand der Formel der Spezifikation nachgerechnet.

Schematischer Ablauf

1. Der Betreiber startet mcp-grafana mit einem HTTP-Transport. Adresse und Token der eigenen Grafana-Instanz stehen in Umgebungsvariablen.
2. Ein Aufrufer, der den HTTP-Endpunkt erreicht, sendet eine MCP-Anfrage mit X-Grafana-URL auf einen Host seiner Wahl und ohne eigenen Token.
3. Der Server übernimmt die Adresse aus dem Header und ergänzt die Zugangsdaten aus der Umgebung.
4. Der nächste Werkzeugaufruf geht samt Token an den fremden Host, der den Token mitschneiden kann.
5. Mit dem Token lässt sich die echte Grafana-Instanz direkt ansprechen, im Rahmen der Rechte des Service-Accounts.

Wir veröffentlichen bewusst keinen Exploit-Code. Die Beschreibung reicht, um die eigene Installation einzuordnen und den Fix nachzuvollziehen.

Wer betroffen war

Der CVE-Eintrag nennt ein einziges Produkt, den Grafana MCP Server, in allen Versionen bis einschließlich 0.17.1. Grafana selbst ist dort nicht als verwundbar aufgeführt. Die Grafana-Instanz ist aber der Ort, an dem ein abgeflossener Token wirkt. Laut Fix-Commit betraf das Verhalten die Transporte HTTP und SSE. Im Quellcode von 0.17.1 liest der stdio-Modus seine Konfiguration nur aus der Umgebung, nicht aus Request-Headern.

Wie groß das Risiko im Einzelfall war, hängt davon ab, wer den HTTP-Endpunkt erreichen konnte: nur der lokale Rechner, ein internes Netz oder das Internet. Und davon, welche Rechte der Service-Account in Grafana hatte.

Behebung und was Betreiber jetzt tun sollten

Was der Fix in 0.17.2 ändert

Die Korrektur bindet Zugangsdaten aus der Umgebung an die in der Umgebung konfigurierte Grafana-Adresse. Zeigt X-Grafana-URL auf eine andere Instanz, hängt der Server weder Service-Account-Token noch veralteten API-Schlüssel, Basic-Auth oder zusätzliche Header aus der Umgebung an. Der Aufrufer muss für diese Adresse eigene Zugangsdaten mitbringen. Für den Vergleich werden beide Adressen vorher normalisiert. Header, die der Betreiber ausdrücklich zur Weiterleitung freigegeben hat (GRAFANA_FORWARD_HEADERS), werden weiterhin durchgereicht. Anfragen ohne X-Grafana-URL oder mit der konfigurierten Adresse verhalten sich wie vorher. Der Fix ergänzt außerdem Tests, die genau diese Fälle abdecken.

Das ist eine strukturelle Lösung: Statt einzelne Ziele zu sperren, hängt die Berechtigung jetzt am Ziel. Die Funktion für mehrere Instanzen bleibt erhalten.

Empfehlungen für Betreiber

Die folgenden Schritte sind unsere Empfehlungen, keine Vorgaben des Herstellers.

Zeitleiste

Aufgeführt sind nur Daten, die sich aus öffentlichen Quellen belegen lassen.

Die korrigierte Version stand damit zwei Tage vor der öffentlichen Beschreibung der Schwachstelle bereit. Das Datum der ursprünglichen Meldung ist nicht öffentlich dokumentiert und deshalb nicht aufgeführt.

Das Muster dahinter: Confused Deputy in MCP-Servern

Hinter CVE-2026-15583 steht ein Muster, das in MCP-Servern naheliegt. Viele Server halten Zugangsdaten des Betreibers und erlauben zugleich, Teile der Konfiguration pro Anfrage zu überschreiben, weil das für mehrere Mandanten oder Instanzen praktisch ist. Gefährlich wird es, sobald Ziel und Zugangsdaten getrennt aufgelöst werden und jede Hälfte für sich auf einen Standardwert zurückfällt. Dann bestimmt der Aufrufer das Ziel, und der Betreiber liefert die Zugangsdaten.

In unserer Erläuterung der OWASP MCP Top 10 berührt der Fall drei Klassen: den Confused Deputy aus Klasse 1, SSRF aus Klasse 5 und Zugangsdaten, die ungeprüft an ein fremdes Ziel weitergereicht werden, aus Klasse 7. Für Entwickler von MCP-Servern lassen sich daraus vier Regeln ableiten:

• Zugangsdaten an das Ziel binden. Ein Token gehört zu genau einem Ursprung. Ändert der Aufrufer das Ziel, bringt er eigene Zugangsdaten mit oder bekommt keine.
• Kein stiller Rückfall. Ein Standardwert für das Geheimnis darf nur greifen, wenn auch das Ziel der Standardwert ist.
• Vom Aufrufer gesetzte Ziele prüfen. Eine Allowlist für Schema und Host, Sperre für interne und Link-Local-Adressen, und bei Fehlern ablehnen statt durchlassen.
• Den Negativfall testen. Ein Test „fremde Adresse ohne Token, es darf kein Token hinausgehen“ fängt diese Klasse dauerhaft ab. Der Grafana-Fix enthält genau solche Tests.

Für Betreiber gilt die Kehrseite: Ein MCP-Server mit HTTP-Transport ist ein Netzwerkdienst mit Ihren Zugangsdaten. Er verdient dieselbe Behandlung wie jede andere API mit Geheimnissen, also Authentifizierung, minimale Rechte und begrenzte ausgehende Verbindungen.

Dank an das Grafana-Security-Team

Wir danken dem Security-Team von Grafana Labs für die koordinierte Zusammenarbeit. Die Meldung lief vertraulich über Grafanas Bug-Bounty-Programm, der CVE-Eintrag vermerkt als Quelle „BUG_BOUNTY“. Grafana Labs hat als CNA die CVE-Nummer vergeben, die korrigierte Version vor der Veröffentlichung bereitgestellt und Advisory und CVE-Eintrag mit Nennung von CyberSec42 veröffentlicht. So sollte koordinierte Offenlegung ablaufen: Betreiber konnten aktualisieren, bevor die Details öffentlich waren.

Häufige Fragen

Weiterlesen

• CVE-2026-114123: Fehlende Authentifizierung im D365 F&O MCP Server erklärt
• CVE-2026-104776: Dateilesen über kubectl_patch in mcp-server-kubernetes erklärt
• CVE-2026-110787: Wie der MCP-Endpunkt von pREST die expose-Einstellungen umging
• Forschung: unsere öffentlich dokumentierten Funde
• Die OWASP MCP Top 10, praktisch erklärt
• MCP-Server absichern: der praktische Leitfaden
• Leistung: KI-Pentest & MCP-Sicherheit

Quellen

• CVE.org: CVE-2026-15583
• NVD: CVE-2026-15583
• Grafana Labs Security Advisory: CVE-2026-15583
• GitHub Advisory Database: GHSA-7cfp-pmw3-4j7r
• GitHub: mcp-grafana Release v0.17.2
• GitHub: mcp-grafana Pull Request #995
• GitHub: Änderungen zwischen v0.17.1 und v0.17.2
• MITRE: CWE-610
• FIRST: CVSS v3.1 Specification
• Model Context Protocol: Transports