BlogIndustry News

MCP Security: What the LiteLLM and Grafana Flaws Mean for You

LiteLLM and Grafana both shipped MCP servers that trusted unauthenticated callers. Here's what broke and the checklist we'd run this week.

MagicMakers Lab13 Oct 20267 min read

Over the past few weeks, two widely used pieces of AI plumbing were caught making the same mistake: trusting callers nobody had authenticated. LiteLLM's MCP endpoint accepted any bearer token, even the single letter "a", and that flaw is now on CISA's Known Exploited Vulnerabilities list. Grafana's MCP server accepted any session ID that merely looked valid. Both sit at the top of Adversa AI's October MCP security roundup.

If your team has hooked an AI assistant up to Jira, Slack, a database or your CRM through the Model Context Protocol, MCP security has left the research papers and landed in your risk register. Below we cover what broke, why the same holes keep showing up, and the checklist we'd run this week.

TL;DR#

LiteLLM (CVE-2026-59822) and Grafana's MCP server (CVE-2026-19516) both let unauthenticated callers use tools that held real credentials. Patch both, and switch Grafana's new auth on.
In independent testing, popular scanners missed working malicious MCP servers, so a clean scan isn't a green light.
Treat every MCP server like a privileged service account: authenticate it, scope it, log it, and keep secrets out of config files.

What happened: three MCP failures in a month#

LiteLLM: any token works#

Wiz researchers found that when a bearer token failed validation, LiteLLM's MCP auth handler caught the error and returned an empty auth object instead of rejecting the request (Wiz). Wiz chained it with a default master key (sk-1234), an unsandboxed guardrail endpoint and pass-through routes that reached the cloud metadata service. The end of that chain was cloud credentials.

The auth bypass was fixed in v1.84.0 and added to CISA's KEV catalog on September 2. Back in June, CISA had already listed a separate LiteLLM command injection in its MCP server testing endpoints, CVE-2026-42271 (Security Affairs).

Grafana MCP: sessions nobody issued#

Pillar Security showed that affected mcp-grafana releases checked only the format of a session ID (Pillar Security). With no inbound authentication, anyone who could reach the server could invent a session and call tools with its Grafana service-account token. A second flaw, CVE-2026-19516 (CVSS 9.1), let a caller-supplied X-Grafana-URL header turn a tool into a server-side request forgery proxy. Version 1.1.0 added optional bearer-token auth.

Scanners that said "clean"#

Pluto Security built a credential thief and a remote-code server disguised as a weather tool, then ran them past five popular MCP scanners. Every scanner returned a clean or zero-finding result for at least one malicious server in at least one setup (Pluto Security).

Why MCP servers make such attractive targets#

An MCP server is a translator with a keyring. The model asks to "create a ticket" or "look up this order", and the server does it with credentials it holds. That's the whole point, and it's also why one auth bug turns into a breach. Wiz says its data shows LiteLLM in roughly one-third of cloud environments.

The keys are often lying around, too. Hush Security looked at about 82,000 public MCP configuration files on GitHub and found that 12% of credential slots held a hardcoded secret (Hush Security). 55% of those secrets had no recognizable vendor format, so the usual secret scanners won't flag them. Of the ones with a defined expiry policy, 80% don't expire by default.

So you get servers that sometimes skip authentication, holding long-lived, broad tokens, installed from packages scanners can't fully vet. None of it is exotic. Web APIs went through the same mistakes years ago. MCP is repeating them faster because the tooling is new and everyone wants agents shipped yesterday.

Technical breakdown: where trust leaks in an MCP setup#

A typical setup:

AI client  →  MCP gateway  →  MCP server  →  Tickets, DB, CRM, cloud
   (1) who is calling?  (2) is the token real?  (3) what can it reach?

Each recent bug broke one of those three checks.

Failure	Real example	What fixes it
Auth fails open	LiteLLM returned an empty identity on a bad token	Reject on any auth error; test with junk tokens
Session ID used as a credential	Grafana MCP accepted any well-formed session ID	Real inbound auth; session IDs as state only
Caller picks the destination	`X-Grafana-URL`, LiteLLM pass-through routes	Allowlist hosts; block private and metadata IPs
Over-scoped credentials	Tools acting with org-wide, non-expiring tokens	One narrow token per server, with owner and expiry
Trusting a scan	Malicious servers passing scanners	Pin versions, review code, trial in a sandbox

The trade-off is friction. Strict auth and narrow tokens mean more setup per tool and more "permission denied" moments while you tune what the agent can do. We think that's a fair price. The protocol's own security best practices point the same way, for example asking servers to use secure, non-deterministic session handles.

What it means for your business#

First, you probably have MCP servers nobody approved. Developers add them to coding tools through a config file. Someone in ops spins up a gateway to try an agent. Neither ends up on an asset list, and nobody knows which tokens those servers hold or who would notice if one leaked.

Second, a vendor-built MCP server isn't safe by default. Grafana is a mature company, and affected releases of its server still shipped without inbound authentication. Ask every vendor how their MCP server authenticates callers and what token scope it needs.

Third, the cost of a mistake scales with what the tools can reach. An agent that reads your help-centre articles is low stakes. One wired into billing, customer records or your cloud account deserves the same review you'd give a new hire with admin rights.

MCP security best practices: a checklist for this week#

Inventory. List every MCP server, gateway and client config across laptops, CI and cloud, including coding assistants.
Patch. LiteLLM to v1.84.0 or later; mcp-grafana to v1.1.0 or later with bearer auth turned on.
Kill defaults and rotate. Replace any default master key and rotate every secret that ever sat in a config file or Git history.
Require inbound auth on every remote MCP endpoint, then prove it fails closed by sending a junk token.
Scope tokens. One service account per server, minimum permissions, a named owner and an expiry date.
Restrict egress. Block loopback, private ranges and the cloud metadata address (169.254.169.254) from MCP hosts.
Pin and review. Install servers from reviewed sources at pinned versions. Treat "no findings" as one signal, not a verdict.
Gate risky actions. Writes, refunds and deletions get a human approval step.
Log every tool call with caller, arguments and result, and alert on unusual volume.

How MagicMakers Lab approaches this#

We build MCP servers and agent integrations the way we'd build anything that touches money or customer data: inbound auth, one narrowly scoped credential per tool, human approval for risky writes and a log of every call, all in the first sprint rather than a hardening phase at the end. It's the same discipline behind Framico, where 200+ orders a day ship with zero manual steps, and Business Hub, where three disconnected systems became one platform. Automation only pays off when you trust what it's allowed to touch.

Key takeaways#

The recent MCP flaws came from basics: auth that fails open, session IDs used as credentials and caller-controlled URLs.
An MCP server holds real credentials, so treat it like a privileged service account.
Hardcoded, non-expiring secrets in MCP configs are common and often invisible to secret scanners.
A clean scan is evidence, not approval.

FAQ#

What is MCP security?#

MCP security covers the controls that stop Model Context Protocol servers, clients and gateways from being misused. That means authenticating who calls a server, limiting what each server's credentials can reach, checking where tools send requests, vetting third-party servers before install and logging every tool call. It's ordinary API and identity security applied to the layer that lets AI models act on your systems.

Is MCP safe to use in production?#

Yes, if you treat each server like any other privileged service. Require inbound authentication, give each server a narrowly scoped token that expires, block access to internal and metadata addresses, and add human approval for risky actions. The LiteLLM and Grafana flaws happened where those basics were missing or switched off, not because the protocol can't be run safely.

How do I add authentication to an MCP server?#

For remote servers, check every request: OAuth or a bearer token validated against your identity provider, rejected on any error. Don't treat a session ID as proof of identity. If you run mcp-grafana, version 1.1.0 added optional bearer-token auth, so turn it on. Then test it by sending a junk token and confirming the request fails.

Can an MCP security scanner tell me if a server is safe?#

Not on its own. In Pluto Security's tests, each of five popular scanners gave a clean or zero-finding result for at least one working malicious server. Several only inspect tool names and descriptions, not the code that runs. Pair scans with pinned versions, code review and a sandboxed trial using fake credentials.

If you're not sure which MCP servers are running in your company, or what their tokens can reach, we'll map it with you and hand you a prioritised fix list. Book a free audit.