Grafana MCP - Session Spoofing and SSRF CVE-2026-19516
- Pillar Security published findings on 2 September 2026 against Grafana's MCP server (
mcp-grafana): a session ID was not authentication. - Clients could mint a locally generated
Mcp-Session-Idin the expected format and reachtools/callwithout a server-issued session - valid format, never issued. - CVE-2026-19516 (CVSS 9.1) covers SSRF through
grafana_api_request/X-Grafana-URL, letting a caller aim Grafana API traffic at attacker-chosen URLs. - Bearer authentication support in
mcp-grafanav1.1.0 is the vendor direction for treating MCP as an identity-bearing surface rather than an open local broker. - The broader lesson is architectural: many MCP servers act as identity brokers to powerful backends. Session cosmetics are not authn, and SSRF on those brokers inherits the backend's reach.
On 2 September 2026, Pillar Security published "valid but never issued" findings against Grafana MCP (mcp-grafana): a session identifier that looked right was treated as enough to call tools, and a separate critical SSRF - CVE-2026-19516 (CVSS 9.1) - let callers steer X-Grafana-URL / grafana_api_request at arbitrary destinations. Together they turn an observability MCP into an identity broker with a forged ticket and a reachable dial tone.
Session spoofing: format is not issuance
MCP session IDs exist so a client and server can correlate a stream of tool calls. They are not, by themselves, proof of login. Pillar showed that Grafana MCP accepted a locally generated Mcp-Session-Id in the expected format for tools/call - never minted by the server, yet honored. That is the difference between a cookie you stole and a cookie you typed to look like one.
Once tools/call is reachable without a real issued session, every tool the MCP exposes becomes an unauthenticated API in front of Grafana's capabilities. That is why bearer auth in mcp-grafana v1.1.0 matters: it reintroduces a credential the server can verify, instead of trusting client-side session cosmetics. Confirm the advisory's exact fixed versions for the spoofing path versus the SSRF path before you mark hosts closed - research notes sometimes land slightly ahead of complete version strings in every channel.
CVE-2026-19516: SSRF on the Grafana dial tone
CVE-2026-19516 (CVSS 9.1) covers SSRF through grafana_api_request and the X-Grafana-URL header. A caller who can invoke that tool can aim the broker's HTTP client at URLs of their choosing. On a developer laptop or an internal automation host, that often means reach into networks the attacker could not hit directly - the classic SSRF premium, now sitting on an MCP tool boundary.
This is the same family of failure as other MCP HTTP brokers that copy attacker-controlled URLs into server-side fetches - see MCP Atlassian SSRF to RCE and Gradio proxy URL SSRF. Grafana MCP is simply a high-value instance because Grafana already sits on privileged observability data and internal routing.
MCP servers as identity brokers
The durable reading is not "one Grafana bug." It is that MCP servers broker identity and reach into systems that already have rich APIs. If session handling is cosmetic and tool arguments can redirect the broker's HTTP client, you have rebuilt a confused-deputy with a JSON-RPC face. OAuth and bearer patterns for MCP exist precisely so the broker has a real subject - background in OAuth for MCP servers and gateway passthrough pitfalls in AI gateway OAuth passthrough for MCP.
Fleet question: which endpoints run mcp-grafana, which agents are connected to it, and which tool calls hit grafana_api_request-style operations? That is an MCP server inventory problem before it is a CVSS argument.
Session and origin mistakes on MCP HTTP are a pattern - see local MCP HTTP DNS-rebinding class for the September SSE/Streamable pair.
How Anomity inventories and governs MCP brokers
Anomity's Endpoint Sensor inventories MCP servers (and agents, skills, extensions, plugins, hooks, CLIs, secrets) on managed endpoints so mcp-grafana connections are visible across Cursor, Claude Code, Codex, and other clients - not buried in one IDE's settings UI. Metadata only leaves the endpoint; secrets are redacted on-device. Cloud discovery covers Google Workspace / GitHub OAuth AI grants that often sit beside these brokers.
On agents that expose a hook such as Claude Code PreToolUse, runtime governance returns allow, deny, or log before the tool call runs. You can deny grafana_api_request-class calls from untrusted contexts while Grafana patches roll out, and keep every decision in a 90-day audit trail routed to SIEM, Slack, email, or Jira. Anomity is SOC 2 Type II and complements Network, EDR, DLP, and GRC - it does not replace patching CVE-2026-19516.
What to do this week
- Inventory every host and agent config referencing
mcp-grafanaor Grafana MCP URLs. - Upgrade to builds that include bearer auth (
v1.1.0+per reporting) and the vendor fix for CVE-2026-19516; verify both issues in the advisory text. - Block or alert on MCP tool calls that set
X-Grafana-URL/ invokegrafana_api_requestfrom non-approved agents. - Treat locally generated session IDs as untrusted in any MCP broker you operate - require server-issued sessions bound to real authn.
- Reconcile MCP brokers against your registry practice so unreviewed observability MCPs cannot appear only on laptops.
Grafana MCP's session spoofing plus CVE-2026-19516 is a clean lesson in MCP broker risk: format is not issuance, and tool-mediated HTTP is SSRF with better branding. Patch the server, require bearer auth, and inventory who connected. To see MCP brokers and tool-call decisions across your fleet, book a 30-minute demo. When the broker skips identity entirely and falls back to env credentials, the damage looks like mcp-atlassian CVE-2026-77254. That sits inside the wider MCP HTTP fallback-auth class.
Frequently asked questions
What did Pillar find in Grafana MCP?
Pillar's 2 September 2026 write-up describes two related failures. First, Grafana MCP accepted a client-generated Mcp-Session-Id that merely matched the expected format, so unauthenticated tools/call was possible without a server-issued session. Second, CVE-2026-19516 (CVSS 9.1) covers SSRF via grafana_api_request and the X-Grafana-URL header, allowing requests to be aimed at arbitrary URLs.
Why is a session ID not authentication?
A session identifier only works as authentication if the server minted it, bound it to a prior login, and rejects IDs it did not issue. If any client can invent a string in the right shape and the server treats that as a live session, the ID is a formatting convention, not a credential. Pillar's framing - valid but never issued - is exactly that failure.
What is CVE-2026-19516?
CVE-2026-19516 is the SSRF issue in Grafana MCP rated CVSS 9.1, involving grafana_api_request behavior and the X-Grafana-URL header. It lets a caller cause the MCP/Grafana path to fetch or contact attacker-controlled URLs, which is severe when the broker runs with network reach into internal Grafana or adjacent services.
How does mcp-grafana v1.1.0 change the auth story?
Reporting highlights bearer authentication support in mcp-grafana v1.1.0 as the fix direction for requiring real credentials on MCP operations rather than trusting a locally invented session ID. Teams should confirm the exact fixed versions for both the session-spoofing behavior and the SSRF CVE in Grafana's advisory text before closing exposure tickets.
How does this compare to other MCP SSRF bugs?
It sits in the same family as other MCP brokers that turn tool arguments into outbound HTTP - for example MCP Atlassian SSRF-to-RCE and Gradio proxy URL SSRF covered elsewhere on this blog. The Grafana case is notable because it combines an authn gap (spoofable session) with a critical SSRF (CVSS 9.1) on a widely deployed observability stack.
How does Anomity help with MCP identity-broker risk?
Anomity inventories MCP servers on endpoints, including remote and local brokers that agents are configured to use, and can apply allow, deny, or log at the agent hook before tool calls run. That does not patch Grafana for you, but it answers which developers connected mcp-grafana, which tool calls targeted grafana_api_request-style operations, and what was denied - in a 90-day audit trail routed to SIEM, Slack, email, or Jira.
