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.
Editorial analysis by NHI Mgmt Group, based on content published by Pillar Security: “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.
- This critical SSRF vulnerability was assigned CVE-2026-19516, with a CVSS score of 9.1.
Key questions
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 identity broker risk?
A: Because the server often executes with its own credentials and network reach, not the caller’s.
Q: What are the signs that MCP destination controls are failing?
A: A warning sign is any tool that can reach caller-selected hosts, private ranges, or metadata endpoints without an explicit allowlist.
Practitioner guidance
- Separate session state from authentication Require a real inbound credential before any MCP tool can run, and treat session identifiers only as protocol correlation values.
- Constrain the server’s own authority Review the service account assigned to each MCP server and remove any permissions that are not strictly required for the enabled tools.
- Lock down outbound destinations Allow only approved hosts and ranges, block loopback, private, link-local, and metadata endpoints by default, and revalidate the resolved address at connection time.
Bottom line: Grafana MCP exposed a control failure where session-like state was accepted without authentication and then used to invoke authority-bearing tools.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
26/08/2026 11:51 am
Session state is not an identity control: Grafana MCP shows that a protocol token can correlate requests without authenticating the caller. That is a foundational governance mistake because it encourages teams to treat transport state as proof of authority. The implication is that NHI and agentic tool access programmes must separate session management from authentication and authorisation.
A few things that frame the scale:
- Only 5.7% of organisations have full visibility into their service accounts, according to the Ultimate Guide to NHIs.
A question worth separating out:
Q: How should security teams govern AI sessions that generate outbound web traffic?
A: Security teams should treat AI sessions as governed activity, not just application usage. The control model needs to bind identity, destination, action, and data handling together so that prompts, tool calls, and file movement are enforced as one session rather than separate events.
👉 Read our full editorial: Grafana MCP session spoofing exposes the identity broker problem