Dating note: both of these were disclosed in September (Grafana’s on September 3, the Python SDK’s on September 28). I’m grouping them because if you run MCP servers or clients, they’re a good excuse for a short audit. I haven’t tested either. This summarizes SC World and The Hacker News.
1. Grafana MCP server: CVE-2026-19516
- Severity: CVSS 9.1 (critical).
- Found by: Pillar Security, which published on September 3. Grafana patched in August.
- Fixed in: Grafana MCP v1.1.0, which also added optional bearer-token protection. SC World doesn’t list the affected versions.
How it works. A caller could pass an X-Grafana-URL header when using the grafana_api_request tool, which let them control the method, path and body of the server’s outbound request. That means the caller could read responses from internal services the MCP server could reach but the caller couldn’t. In Pillar’s tests, certain setups allowed retrieving AWS IMDSv2 credentials from the instance metadata service.
A related weakness (no CVE cited). The server checked only the format of session IDs, not whether they were real. An unauthenticated caller could invent a session-shaped ID and call tools, and Pillar said that could be chained with the first flaw. Grafana called the bearer-token addition “a security improvement rather than a vulnerability.”
Pillar says the new flaw did not let callers obtain the Grafana service-account token, which an earlier fix (CVE-2026-15583) addressed.
What to do: update to v1.1.0 or later and require authentication on any remote deployment. Pillar also recommends an explicit destination policy for any tool that makes HTTP requests.
2. MCP Python SDK: OAuth flaw
- Advisory: GHSA-qx49-fqc8-xw99, published September 28. No CVE was assigned as of September 29.
- Severity: CVSS 7.5 for the two machine-to-machine providers, 6.5 for the interactive one.
- Found by: Cycode, with eight credited reporters.
How it works. A malicious MCP server could point an SDK client at an authorization server of its choosing. The client then sends its client secret, authorization code and PKCE proof key to that server. The attacker can use them to request tokens from the real login service, and the client secret is long-lived until rotated.
Affected:
| Line | Affected | Fixed |
|---|---|---|
| 1.x | 1.9.1 to 1.29.1 | 1.30.0 |
| 2.x | 2.0.0 to 2.1.1 | 2.2.0 |
It applies to HTTP clients using the OAuth providers when connecting to servers you don’t fully trust. Servers built with the SDK, stdio clients, and clients that attach their own tokens are not affected.
The catch: for ClientCredentialsOAuthProvider and PrivateKeyJWTOAuthProvider, the advisory says upgrading alone changes nothing until you also pass issuer=. The deprecated RFC7523OAuthClientProvider has no issuer option, so move off it. Clear stored OAuth client registrations once after upgrading. If a client may have connected to an untrusted server, rotate its secret and revoke its tokens. Neither the advisory nor Cycode reports attacks in the wild.
The common thread
In both cases the server or client trusted something it was handed: a URL header, a session ID, an authorization server named by the other side. That’s the same shape as the LiteLLM bug I covered in this post. MCP makes it easy to connect agents to tools, which is exactly why every connection needs a clear answer to “who is allowed to say this, and how do I check?”
A quick audit takes ten minutes: list the MCP servers and clients you run, check versions against the above, and make sure none is reachable from places it doesn’t need to be.
Sources: SC World, The Hacker News.
