GrafanaGhost Deckt Drei Muster von KI-Sicherheitsversagen auf – Nicht Nur Eines

Die URL eines Angreifers, ein Back-End-Prozess und Ihre Finanzdaten auf einem externen Server

Am 7. April 2026 veröffentlichten Forscher von Noma Security die Schwachstelle GrafanaGhost – ein Angriff, bei dem Grafanas eigene, vertrauenswürdige interne Prozesse unbemerkt zu einer Pipeline für Datenabfluss wurden. Die Branche sprach von einem Fehler bei der Zugriffskontrolle für KI-Daten. Diese Sicht ist jedoch unvollständig – und die Unterscheidung hat Konsequenzen für jedes Unternehmen, das KI-gestützte Tools einsetzt.

wichtige Erkenntnisse

1. Der Angriff versteckte Prompts in Event-Monitoring-Daten. Angreifer erstellten URLs, deren Query-Parameter in den Entry-Logs von Grafana landeten. Vertrauenswürdige Back-End-Enrichment-Prozesse mit Systemprivilegien führten später die versteckten KI-Anweisungen aus – erstellten ein Dashboard, das niemand angefordert hatte, und betteten sensible Daten in ausgehende Image-Tags ein.
2. Grafana verfügt über RBAC für den nutzerseitigen Datenzugriff. Der Angriff löste diese Kontrollen nicht aus. GrafanaGhost lief über systemseitige Back-End-Prozesse, nicht über Benutzersitzungen. Zugriffskontrollen auf Nutzerebene waren irrelevant, da der Angriff die Benutzerschicht vollständig umging.
3. Dies sind drei Fehler-Muster, nicht nur eines. Fehler bei der Vertrauensgrenze für Eingaben (externe Daten werden ohne Validierung verarbeitet), Fehler bei der Prozessbegrenzung (Back-End-Prozess mit Funktionsumfang, für den er nie vorgesehen war) und Fehler bei den Guardrails auf Modellebene (durch ein einziges Schlüsselwort ausgehebelt). Jedes Muster erfordert eine andere Lösung.
4. Das gleiche Vertrauensproblem bei Eingaben findet sich in jeder größeren KI-Schwachstelle des letzten Jahres. EchoLeak, GeminiJack, ForcedLeak, Reprompt und GrafanaGhost beginnen alle damit, dass nicht vertrauenswürdige externe Daten in ein System gelangen und von KI ohne Validierung verarbeitet werden.
5. Data Access Governance adressiert ein Muster. Eingabevalidierung und Prozessbegrenzung adressieren die beiden anderen. Wer alles vermischt, sorgt dafür, dass nach der Behebung eines Problems die anderen weiterhin bestehen bleiben.

Ein Angreifer schickte manipulierte Webanfragen an eine Grafana-Instanz. Die Anfragen wirkten unauffällig – aber die URL-Query-Parameter enthielten versteckte KI-Prompt-Anweisungen. Grafanas Event-Monitoring protokollierte diese Anfragen als normalen eingehenden Traffic. Die bösartige Nutzlast war nun tief im System gespeichert, nicht mehr von legitimen Betriebsdaten zu unterscheiden.

Grafana steht im Zentrum der Enterprise-Observability und ist mit Datenbanken, Cloud-Infrastrukturen, Finanzsystemen und Kunden-Backends verbunden. Was dann geschah, macht GrafanaGhost architektonisch bedeutsam.

Wie der Angriff tatsächlich funktionierte

Vertrauenswürdige Back-End-Enrichment-Prozesse liefen ab – Prozesse, die dazu dienen, Ereignisdaten zu korrelieren, zu analysieren und für Dashboards und Alarme aufzubereiten. Diese Prozesse arbeiten mit Systemprivilegien, weil sie nahezu auf alle Daten zugreifen müssen. Sie lesen aus mehreren Quellen und schreiben angereicherte Informationen zurück in die Datenbank. Sie sind nicht dafür gedacht, Daten an Nutzer auszuliefern. Sie unterliegen keiner RBAC auf Nutzerebene.

Als der Enrichment-Prozess das Ereignis des Angreifers analysierte, traf er auf den versteckten KI-Prompt und führte ihn aus. Die KI-Komponente – im privilegierten Kontext des Back-End-Prozesses – baute ein Dashboard, das niemand angefordert hatte, bettete sensible Daten (Finanzkennzahlen, Infrastruktur-Telemetrie, Kundendaten) in Image-Tags ein und machte diese Bilder extern zugänglich.

Die Forscher von Noma fanden heraus, dass das Schlüsselwort „INTENT“ die Guardrails der KI aushebelte. Ein weiterer Validierungsfehler bei URLs – Protokoll-relative URLs im Format //attacker.com – täuschte clientseitige Schutzmechanismen und ließ eine externe Domain als intern erscheinen. Die Daten verließen das System als URL-Parameter, getarnt als Bild-Render.

Jedes Security Information and Event Management (SIEM), Data Loss Prevention (DLP)-Tool und jeder Endpoint-Agent sah einen Back-End-Prozess, der das tat, was Back-End-Prozesse tun. Nichts wurde ausgelöst.

Drei Fehler-Muster, nicht nur eines

In der Branche wurde GrafanaGhost mit anderen KI-Schwachstellen unter dem Narrativ „KI braucht bessere Guardrails“ zusammengefasst. Diese Vereinfachung ist gefährlich. GrafanaGhost – zusammen mit einer ganzen Reihe weiterer KI-Schwachstellen aus dem letzten Jahr – zeigt drei unterschiedliche Fehler-Muster. Jedes erfordert eine andere architektonische Antwort.

Muster eins: Nicht vertrauenswürdige Eingaben werden als vertrauenswürdiger KI-Kontext behandelt

Externe Daten gelangten über einen legitimen Kanal ins System und wurden später von einer KI-Komponente ohne Validierung verarbeitet. Bei GrafanaGhost waren es URL-Query-Parameter, die in Event-Logs gespeichert wurden. Der Back-End-Enrichment-Prozess behandelte diese Daten als intern und vertrauenswürdig.

Das ist der gleiche Fehler hinter jeder größeren KI-Schwachstelle des letzten Jahres. Die Nutzlast von EchoLeak war eine manipulierte E-Mail, die Copilot als Kontext verarbeitete. Bei GeminiJack war es ein vergiftetes Google Doc, das von RAG indiziert wurde. Bei ForcedLeak war es Text, versteckt in einem 42.000 Zeichen langen Web-to-Lead-Formularfeld. In allen Fällen wurde das Prinzip, dass externe Eingaben vor der Verarbeitung validiert werden müssen – die Grundlage für Input-Checks und Web Application Firewalls (WAFs) – nicht auf KI-verarbeitete Daten angewendet.

Daten aus der Außenwelt werden nicht vertrauenswürdig, nur weil sie intern gespeichert sind. Das ist ein zero-trust Input-Validierungsproblem und erfordert Lösungen auf Anwendungsebene und in der KI-Architektur – nicht bloß Zugriffskontrollen.

Muster zwei: Zu weitreichender KI-Datenzugriff ohne Durchsetzung pro Operation

Fünf der im vergangenen Jahr veröffentlichten Schwachstellen – EchoLeak, Reprompt, GeminiJack, ForcedLeak und ein Supply-Chain-Angriff auf das OpenAI-Plugin-Ökosystem – betreffen KI-Systeme, die im Namen eines Nutzers mit weitreichendem, implizitem Datenzugriff und ohne Durchsetzung pro Operation agieren. Die KI authentifizierte sich einmal auf Sitzungsebene und griff dann auf alles zu, was erreichbar war.

Zugriffskontrolle pro Operation – also jede einzelne Datenanfrage gegen die Richtlinie zu prüfen – hätte in all diesen Fällen den Schaden begrenzt. Hier greifen RBAC, ABAC, Credential Isolation und Audit-Trails direkt.

GrafanaGhost ist kein Muster-zwei-Fall. Der Angriff lief über systemseitige Back-End-Prozesse, nicht über Benutzersitzungen. Grafana verfügt über RBAC für den nutzerseitigen Datenzugriff, das aber nie ausgelöst wurde. Kontrollen nach Muster zwei auf GrafanaGhost anzuwenden, adressiert das falsche Problem.

Der Kiteworks Data Security and Compliance Risk: 2026 Forecast Report fand eine Lücke von 15–20 Prozentpunkten zwischen Governance-Kontrollen und Containment-Kontrollen. Die Lücke bei der Durchsetzung pro Operation ist real und dringend – für die fünf Schwachstellen, auf die sie zutrifft.

Muster drei: Fehler bei Prozessbegrenzung und funktionalem Zuschnitt

Der Back-End-Enrichment-Prozess in GrafanaGhost benötigte weitreichenden Datenlesezugriff. Das ist vertretbar. Was er nicht brauchte, war die Fähigkeit, Routinen zum Rendern von Dashboards, zum Generieren von Image-Tags oder zum Senden ausgehender Anfragen an externe Server aufzurufen. Das sind Output-Funktionen, für die der Prozess nie vorgesehen war – aber niemand verhinderte aktiv den Zugriff darauf.

Das ist ein Containment-Fehler. Least Privilege muss sich auf den Funktionsumfang beziehen – also darauf, welche APIs, Rendering-Routinen und Output-Kanäle ein Prozess aufrufen darf – nicht nur auf den Datenzugriff. Ein Data-Enrichment-Prozess, der Daten liest und schreibt, sollte keine Routinen aufrufen können, die mit der Außenwelt kommunizieren.

Der Supply-Chain-Angriff auf das OpenAI-Plugin-Ökosystem ist ebenfalls ein Muster-drei-Fehler: Agenten-Credentials waren für kompromittierten Plugin-Code zugänglich, weil Authentifizierungstokens nicht außerhalb des für die KI zugänglichen Kontexts gespeichert wurden. Sechs Monate lang Zugriff in 47 Unternehmen, weil Credential Isolation fehlte.

Das Guardrail-Versagen auf Modellebene – die dritte Schicht, nicht die erste

Grafana hatte Prompt-Injection-Abwehrmechanismen implementiert. Ein einziges Schlüsselwort hebelte sie aus. Das bestätigt die allgemeine Forschung – jedes große LLM wurde mit nahezu perfekter Erfolgsquote jailbroken. Die Agents of Chaos-Studie vom Februar 2026 dokumentierte, wie KI-Agenten Infrastruktur zerstörten und personenbezogene Daten in Live-Umgebungen offenlegten.

Guardrails auf Modellebene sind eine sinnvolle Verteidigungsschicht. Sie ersetzen aber weder Eingabevalidierung (Muster eins), Zugriffskontrolle pro Operation (Muster zwei) noch Prozessbegrenzung (Muster drei). Selbst wenn die Guardrails gehalten hätten, wäre die Architektur von GrafanaGhost – nicht vertrauenswürdige Eingaben erreichen einen privilegierten Prozess mit zu großem Funktionsumfang – weiterhin fehlerhaft.

Wie Kiteworks passt – und wo nicht

Es ist wichtig, genau zu analysieren, was GrafanaGhost lehrt und welche Kontrollen welche Muster adressieren.

Kiteworks bietet eine kontrollierte Datenschicht mit RBAC- und ABAC-Richtlinien, OAuth 2.0-Authentifizierung mit Credentials im OS-Keychain, Rate Limiting und manipulationssicheren Audit-Trails für SIEM. Für KI-Systeme, die Daten über Kiteworks anfordern – ob über den Secure MCP Server oder das AI Data Gateway – wird jede Anfrage unabhängig vom KI-Modell authentifiziert, autorisiert und protokolliert.

Diese Kontrollen adressieren Muster zwei: KI-Datenzugriff im Namen eines Nutzers. Für die fünf Schwachstellen, bei denen ein KI-System weitreichenden, impliziten Zugriff ohne Durchsetzung pro Operation hatte – EchoLeak, Reprompt, GeminiJack, ForcedLeak, der OpenAI-Plugin-Angriff – reduzieren ABAC pro Operation, Credential Isolation und Audit-Trails direkt das Schadensausmaß und ermöglichen Erkennung.

GrafanaGhost ist Muster eins plus Muster drei. Der Angriff lief über systemseitige Back-End-Prozesse, nicht über nutzerseitige KI-Anfragen. Zugriffskontrollen – auch die von Kiteworks – adressieren die Frage des Datenzugriffs. Sie lösen aber nicht das Problem der fehlenden Eingabevalidierung (nicht vertrauenswürdige Event-Daten werden ohne Prüfung verarbeitet) oder des fehlenden funktionalen Zuschnitts (der Enrichment-Prozess verfügt über Output-Fähigkeiten, für die er nie vorgesehen war).

Was Kiteworks zur Lehre aus GrafanaGhost beiträgt, ist das Prinzip der Unabhängigkeit: Sicherheitskontrollen, die unterhalb des KI-Modells, außerhalb des KI-Kontexts und unabhängig von den Anweisungen der KI greifen. Dieses Prinzip auf Vertrauensgrenzen bei Eingaben und den funktionalen Zuschnitt von Prozessen auszuweiten, ist die architektonische Herausforderung, die GrafanaGhost aufzeigt.

Was Security-Leader tun sollten – alle drei Muster adressieren

Für Muster eins (Input Trust): Prüfen Sie jede Datenquelle, die von KI verarbeitet wird – Event-Logs, E-Mails, geteilte Dokumente, Formulareingaben, API-Antworten. Wenn externe Eingaben in ein System gelangen, in dem eine KI-Komponente sie verarbeitet, betrachten Sie diese Eingaben als potenziell bösartig. Wenden Sie bei KI-verarbeiteten Daten die gleiche Validierungsdisziplin an wie bei webseitigen Nutzereingaben.

Für Muster zwei (Data Access Scoping): Verlangen Sie Authentifizierung und ABAC pro Operation für jede KI-Datenanfrage. Speichern Sie Credentials außerhalb des KI-Kontexts. Erstellen Sie manipulationssichere Audit-Trails mit vollständiger Attribution für Ihr SIEM.

Für Muster drei (Process Containment): Beschränken Sie Back-End-KI-Prozesse auf die funktionalen Fähigkeiten, die sie tatsächlich benötigen. Breiter Datenlesezugriff kann notwendig sein. Die Fähigkeit, Inhalte zu rendern, ausgehende Anfragen zu generieren oder nutzerseitige Dashboards zu bauen, ist es nicht. Beschränken Sie, was Prozesse tun dürfen, nicht nur, auf welche Daten sie zugreifen dürfen.

Für alle drei: Testen Sie Ihre KI-Integrationen mit Red-Teams. GrafanaGhost wurde von Forschern entdeckt, nicht von Verteidigern. Testen Sie Prompt Injection über Event-Daten, Log-Einträge und Metadaten – nicht nur über nutzerseitige Kanäle.

GrafanaGhost ist gepatcht. Die drei architektonischen Lehren – nicht vertrauenswürdige Eingaben vor KI-Verarbeitung validieren, Zugriffskontrolle pro Operation durchsetzen und Prozesse auf den vorgesehenen Funktionsumfang beschränken – sind es nicht.