Grafana MCP has come under security scrutiny after researchers found a dangerous combination of unauthenticated tool access and server-side request forgery, or SSRF, that could expose sensitive internal systems. The issue matters because Grafana is widely used to monitor production metrics, logs, traces, and incidents, making it a high-value target in enterprise environments.
Pillar Security reported that affected Grafana MCP deployments allowed a reachable caller to invoke MCP tools without authentication by using a locally generated session value in the expected format. In practice, this meant an attacker could call tools such as tools/list and tools/call even without presenting a real credential, and the server would still use its configured Grafana service account on the attacker’s behalf. Grafana responded by adding optional bearer-token authentication in v1.1.0, which returns a 401 error before tool execution when configured.
The second flaw was more subtle but equally dangerous. The grafana_api_request tool accepted an X-Grafana-URL value that let the caller choose the outbound destination, along with the method, path, body, and headers . Although Grafana had already prevented its service-account token from being sent to foreign hosts, the server still made the request and returned the response, which created a critical SSRF condition assigned CVE-2026-19516 with a CVSS score of 9.1.
Researchers showed that this SSRF primitive could be used to reach internal services and even simulate a cloud metadata flow in a controlled environment . That is important because the danger is not limited to token leakage; the server itself becomes a readable and method-capable proxy from its own network position, extending the attacker’s reach beyond what they could access directly.
The broader lesson is that MCP servers can function like identity brokers, translating user instructions into privileged actions performed with the server’s credentials and network access . Session identifiers, host validation, and origin checks may help with protocol state, but they do not replace authentication or authorization. For operators, the practical defense is clear: require inbound authentication, minimize service-account permissions, restrict outbound destinations with strict allowlists, and block private, loopback, and metadata ranges by default .
Read the original article: