Format validation is the old bug. A server that accepts anything shaped like a session ID is doing what web applications did with guessable cookies before 2010: treating a syntax match as proof of issuance. Pillar Security's finding is that the Grafana MCP server validated the format of a session ID rather than checking for a valid credential, so an unauthenticated caller could mint an ID the server never issued and use it to call tools [4].
On its own that is trespass. The tool on the other side of it is what turns trespass into collection. The `grafana_api_request` tool accepted an `X-Grafana-URL` header and let the caller set the HTTP method, path and body of the outbound request, then returned the output [3]. That is CVE-2026-19516, CVSS 9.1, and Pillar reported that the two together form a chain for pulling data out of the internal network hosting the server [2][5].
The demonstration was cloud metadata. Pillar issued a PUT with a TTL header to obtain an IMDSv2 session token, then a second request using that token to retrieve credentials [8]. Count the prerequisites for that sequence: no issued credential and two proxied requests [3]. Pillar's Ariel Fogel wrote that this does not mean every Grafana MCP deployment can reach cloud metadata, and that the property being shown is the server becoming a readable, method-capable proxy from its own network location [9].
The two halves were treated differently. CVE-2026-19516 was fixed in Grafana MCP v1.1.0 [7]. The session validation issue was addressed in the same release by adding optional bearer-token protection, which Pillar says Grafana considered a security improvement rather than a vulnerability [6]. Upgrading therefore closes the reach and leaves the access open until someone enables the tokens [1]. Only the SSRF half carries a tracking identifier in the reporting, which is also the half a scanner will find [2].
`X-Grafana-URL` has produced this shape before. Grafana previously patched CVE-2026-15583, which stopped the Grafana service-account token being exfiltrated to external websites through a crafted version of the same header [10]. Two vulnerabilities, one caller-controlled destination input [4]. Pillar confirmed the new flaw did not yield the service-account token itself [11]. Its recommendation is to treat MCP servers as identity brokers, require authentication on remote deployments, and give any tool that can issue HTTP requests an explicit destination policy [12].
