Notifications
Clear all
Topic starter
26/08/2026 11:50 am
TL;DR: Grafana MCP let unauthenticated callers invoke tools with the server’s service account and direct outbound HTTP requests to attacker-chosen destinations, creating a 9.1 CVSS SSRF path and a separate authentication failure, according to Pillar Security. The case shows that session state, not caller identity, was being treated as the boundary, so MCP deployments need explicit inbound authentication and destination controls.
NHIMG editorial — based on content published by Pillar Security covering Grafana MCP session spoofing and SSRF: Valid, But Never Issued: Session Spoofing and SSRF in Grafana MCP
By the numbers:
- Grafana Labs reports more than 1.5 million active installations and 25 million global users.
- The critical SSRF vulnerability in Grafana MCP was assigned CVE-2026-19516 with a 9.1 CVSS score.
Questions worth separating out
Q: What breaks when MCP servers rely on session-bound state or the initialize handshake?
A: Older draft patterns fail when a request lands on a different instance or when client capabilities change between calls.
Q: Why do MCP tool servers create a larger blast radius than simple APIs?
A: They often combine caller input, stored credentials, and outbound network reach in one component.
Q: How should security teams measure whether MCP egress controls are working?
A: They should test whether the server can reach only approved destinations, whether resolved IPs are rechecked at connect time, and whether requests to private or metadata ranges are blocked.
Practitioner guidance
- Separate session state from authentication Require a real caller identity before any MCP tool with authority-bearing access can execute.
- Lock down tool egress destinations For any HTTP-request capability, maintain a strict allowlist of approved origins and revalidate the resolved address at connection time.
- Minimise MCP service-account authority Give the server only the Grafana permissions required for the enabled tools, and separate read-only telemetry access from any action-capable path.
What's in the full report
Pillar Security's full research covers the technical detail this post intentionally leaves at the governance level:
- The exact session-spoofing behaviour observed in Grafana MCP and how the server accepted tool calls without authenticating the caller
- The SSRF request-flow details, including destination control behaviour and why token protection did not eliminate proxy risk
- The controlled demonstration findings that show how the server’s own authority can be reused against internal and metadata-style endpoints
- The specific release and fix behaviour in Grafana MCP v1.1.0, including the added bearer-token option and logging changes
👉 Read Pillar Security’s analysis of Grafana MCP session spoofing and SSRF →
Grafana MCP session spoofing: are your tool controls enough?
Explore further
26/08/2026 11:51 am
Session spoofing is not the real failure. The failure is treating protocol state as identity. In MCP deployments, a session identifier can organise requests without proving caller legitimacy. That assumption breaks the moment the server can act with its own credentials, because the tool boundary becomes a trust boundary by accident. The practical conclusion is that tool exposure and caller authentication must be designed as one control plane, not two separate checks.
A few things that frame the scale:
- 80% of organisations report their AI agents have already performed actions beyond their intended scope, including accessing unauthorised systems (39%), inappropriately sharing sensitive data (31%), and revealing access credentials (23%), according to AI Agents: The New Attack Surface report.
- Only 52% of companies can track and audit the data their AI agents access, leaving 48% with a complete blind spot for compliance and breach investigation.
A question worth separating out:
Q: Who is accountable when an MCP server authorises the wrong action?
A: Accountability sits with the teams that designed and operated the consent, token validation, and scope controls, because MCP makes authorisation decisions part of the system boundary. In regulated environments, the question is not only who clicked approve but who allowed client identity, audience, and delegation checks to remain incomplete.
👉 Read our full editorial: Grafana MCP session spoofing exposes the identity broker problem
