Grafana fixes critical SSRF flaw affecting Grafana MCP servers

Two weaknesses in the Grafana MCP server implementation, including a critical server-side request forgery (SSRF) flaw, were patched by Grafana last month, according to a report by Pillar Security published Wednesday.

The SSRF vulnerability, tracked as CVE-2026-19516 with a CVSS score of 9.1, could have allowed an MCP caller to leverage the Grafana MCP server’s network position to make requests to internal addresses that would not have otherwise been reachable.

Pillar Security, which discovered and reported the flaw, also reported an additional weakness that allowed an unauthenticated caller to generate their own session ID and use it to call tools via the Grafana MCP. This was due to the MCP server validating the session ID format rather than checking for a valid credential, allowing “session-shaped IDs” that the server never issued to be accepted, Pillar researchers explained.

These unauthenticated tool calls could be paired with the SSRF vulnerability to form a “killchain,” Pillar said, potentially allowing an unauthorized attacker to retrieve sensitive information from the internal network hosting the MCP server. Grafana added optional bearer-token protection in Grafana MCP v 1.1.0 to address the session validation issue, although the company considered this “a security improvement rather than a vulnerability,” Pillar said.

Related reading:

CVE-2026-19516, also fixed in v1.1.0, allowed a caller to supply an “X-Grafana-URL” request header when calling the “grafana_api_request” tool, which enabled them to control the HTTP method, path and body of the outbound request. An attacker could receive the output of requests to internal services reachable by the Grafana MCP server, leveraging the server’s network position to reach otherwise inaccessible destinations.

Pillar demonstrated in tests how this could be exploited in certain setups to retrieve cloud credentials from the AWS Instance Metadata Service (IMDSv2), first using a PUT request and TTL header to obtain the metadata session token and then issuing a second request leveraging that token to retrieve the credentials.

“This does not mean that every Grafana MCP deployment could reach cloud metadata. However, it shows the relevant security property: the server can become a readable, method-capable proxy from its own network location,” Pillar AI Security Researcher Ariel Fogel wrote in the report.

Grafana previously patched a vulnerability tracked as CVE-2026-15583, preventing the Grafana service-account token from being exfiltrated to external websites via a crafted X-Grafana-URL request header. Pillar confirmed that the flaw they discovered did not allow the caller to obtain the service-account token itself but noted that the MCP server’s “authentication posture” could still be exploited as a proxy to sensitive internal data.

Pillar concluded that organizations should view MCP servers as “identity brokers,” giving human and AI callers the ability to perform actions under the server’s privileges and network access. They recommend that tools capable of issuing HTTP requests should have an explicit destination policy and that remote MCP deployments should require authentication.

“The caller provides the instruction and the server provides the reach. Security depends on keeping those two things connected,” Pillar concluded.