Our research

CVE-2026-15583: SSRF in the Grafana MCP Server Explained

By Lucas Weber, CyberSec42 · Updated 28 Oct 2026

CVE-2026-15583 is a server-side request forgery (SSRF) of the confused-deputy kind in the open source Grafana MCP Server (mcp-grafana): by setting the X-Grafana-URL request header, an unauthenticated caller could choose the host to which the server sent its environment-configured Grafana credentials. The CVE record rates it CVSS 8.6 (high) and lists every version up to and including 0.17.1 as affected. It is fixed in version 0.17.2, released on 13 July 2026, and the CVE record credits CyberSec42 as the finder.

Key facts

Background: what an MCP server is and why it holds credentials

The Model Context Protocol (MCP) is an open standard that lets AI assistants call tools and data sources. An MCP server sits in the middle: it accepts tool calls from an AI client and turns them into calls against a target system. According to its documentation, the Grafana MCP Server gives AI assistants access to a Grafana instance, so they can query metrics and logs, search and manage dashboards, manage alert rules, and work with features such as Grafana Incident and Sift.

To do any of that, the server needs Grafana credentials. Operators typically put the instance URL and a service account token into environment variables (GRAFANA_URL and GRAFANA_SERVICE_ACCOUNT_TOKEN, formerly GRAFANA_API_KEY). From then on the server acts with that token's privileges, on behalf of anyone who can reach it. That is what makes an MCP server an attractive target: it is a deputy with authority. General hardening advice lives in our guide to securing MCP servers; this article covers one specific case.

The deployment mode, which MCP calls the transport, is key to understanding the issue. The Grafana MCP Server supports three: stdio (the default, where the AI client launches the server as a local process), plus sse and streamable-http (where the server runs as a network service and accepts HTTP requests). On the HTTP transports the server can also read configuration per request from headers, including X-Grafana-URL for the target address and dedicated headers for a token. The source code describes this as support for multi-tenant scenarios, which is a useful feature. The vulnerability sat in how those headers interacted with the environment-configured credentials.

The vulnerability

In plain words

Picture a courier who collects documents from your bank using your company ID. Any client may give the courier a different address, in case the bank has several branches. But the courier never checks whether the new address still belongs to your bank, and shows your company ID at every door. Anyone who gives the address of their own office gets to see your ID and can copy it.

That is how the Grafana MCP Server behaved up to version 0.17.1. The ID is the service account token, the address is the X-Grafana-URL header.

In detail

The server resolved the target URL and the credentials independently, and each had its own fallback to the environment. The commit message of the fix describes it the same way. If a request carried X-Grafana-URL but no token header of its own, the server took the URL from the header and the token from the environment. The same applied to basic auth and to extra headers the operator had configured in the environment. Such headers can carry secrets themselves, an Authorization header for example. The next call to “Grafana” therefore went, together with the operator's credentials, to a host the caller had picked.

The term confused deputy describes exactly this situation: a service with authority (the deputy) is tricked by someone without that authority into using it for someone else's purposes. The CVE record also states that the same mechanism enables SSRF against arbitrary internal services, including cloud metadata endpoints. Grafana's advisory calls it “credentialed SSRF”, meaning requests to internal targets that also carry credentials.

Reading the vector: PR:N and UI:N mean neither a login nor any user action was needed. S:C (scope changed) means, per the CVSS specification, that the impact reaches beyond the vulnerable component. The MCP server was vulnerable, while the impact lands on the Grafana instance whose token could leak. C:H stands for the loss of confidentiality; according to the vector, integrity and availability of the server itself are not affected. We recomputed the 8.6 base score from the formula in the specification.

Schematic flow

1. The operator runs mcp-grafana with an HTTP transport. The URL and token of their own Grafana instance sit in environment variables.
2. A caller who can reach the HTTP endpoint sends an MCP request with X-Grafana-URL pointing at a host of their choice, without a token of their own.
3. The server takes the URL from the header and fills in the credentials from the environment.
4. The next tool call goes to the foreign host with the token attached, and that host can record it.
5. With the token, the real Grafana instance can be called directly, within the privileges of the service account.

We deliberately publish no exploit code. The description is enough to assess your own deployment and to follow the fix.

Who was affected

The CVE record names a single product, the Grafana MCP Server, in all versions up to and including 0.17.1. Grafana itself is not listed as vulnerable, but the Grafana instance is where a leaked token takes effect. According to the fix commit, the behaviour affected the HTTP and SSE transports. In the 0.17.1 source code, stdio mode reads its configuration from the environment only, not from request headers.

The actual risk in a given deployment depends on who could reach the HTTP endpoint (only the local machine, an internal network or the internet) and on the privileges of the service account in Grafana.

The fix and what operators should do now

What changed in 0.17.2

The fix binds environment-configured credentials to the Grafana URL configured in the environment. If X-Grafana-URL points at a different instance, the server no longer attaches the service account token, the deprecated API key, basic auth or extra headers from the environment. The caller has to supply their own credentials for that URL. Both URLs are normalised before they are compared. Headers the operator has explicitly chosen to forward (GRAFANA_FORWARD_HEADERS) are still passed on. Requests without X-Grafana-URL, or with the configured URL, behave as before. The fix also adds tests that cover exactly these cases.

It is a structural fix: rather than blocking individual targets, the authority is now tied to the target. Multi-instance support stays intact.

Recommendations for operators

The following steps are our recommendations, not vendor requirements.

Timeline

Only dates that can be verified from public sources are listed.

The fixed version was therefore available two days before the vulnerability was described publicly. The date of the original report is not publicly documented and is therefore not listed.

The underlying pattern: confused deputies in MCP servers

Behind CVE-2026-15583 lies a pattern that comes naturally to MCP servers. Many servers hold the operator's credentials and at the same time let callers override parts of the configuration per request, because that is convenient for multiple tenants or instances. It turns dangerous as soon as target and credentials are resolved separately and each half falls back to a default on its own. The caller then picks the target, and the operator supplies the credentials.

In our walkthrough of the OWASP MCP Top 10, this case touches three classes: the confused deputy from class 1, SSRF from class 5, and credentials forwarded unchecked to a foreign destination from class 7. For developers of MCP servers it boils down to four rules:

• Bind credentials to the target. A token belongs to exactly one origin. If the caller changes the target, they bring their own credentials or get none.
• No silent fallback. A default secret may only apply when the target is also the default.
• Validate caller-supplied targets. Allowlist scheme and host, block internal and link-local addresses, and reject on error instead of letting the request through.
• Test the negative case. A test along the lines of “foreign URL without a token, no token may leave” catches this class for good. The Grafana fix contains exactly such tests.

For operators, the flip side applies: an MCP server with an HTTP transport is a network service holding your credentials. It deserves the same treatment as any other API with secrets, meaning authentication, least privilege and restricted outbound connections.

Thanks to the Grafana security team

We thank the Grafana Labs security team for the coordinated collaboration. The report was submitted confidentially through Grafana's bug bounty programme, and the CVE record lists “BUG_BOUNTY” as its source. Grafana Labs assigned the CVE as CNA, shipped the fixed version ahead of publication, and published the advisory and the CVE record crediting CyberSec42. This is how coordinated disclosure should work: operators were able to upgrade before the details became public.

Frequently asked questions

Further reading

• CVE-2026-114123: Missing Authentication in the D365 F&O MCP Server Explained
• CVE-2026-104776: File Read via kubectl_patch in mcp-server-kubernetes Explained
• CVE-2026-110787: How the pREST MCP Endpoint Bypassed the expose Settings
• Research: our publicly documented findings
• The OWASP MCP Top 10, Explained in Practice
• Securing MCP Servers: A Practical Guide
• Service: AI pentest & MCP security

Sources

• CVE.org: CVE-2026-15583
• NVD: CVE-2026-15583
• Grafana Labs security advisory: CVE-2026-15583
• GitHub Advisory Database: GHSA-7cfp-pmw3-4j7r
• GitHub: mcp-grafana release v0.17.2
• GitHub: mcp-grafana pull request #995
• GitHub: changes between v0.17.1 and v0.17.2
• MITRE: CWE-610
• FIRST: CVSS v3.1 specification
• Model Context Protocol: Transports