Table of contents
17
By Salman Khan, OSCP+, Founder of XHack, SRT (Synack Red Team member)
Read this in 30 seconds: MCP server vulnerabilities, the kind of MCP server vulnerabilities worth a hunter’s time, are a real, current, under-tested attack surface, confirmed by NVD-verified CVEs like a 9.8 command injection in LiteLLM’s MCP server creation flow and a confused-deputy prompt injection in Kong’s Konnect MCP server, and most bug bounty programs haven’t caught up to how to scope or pay for them yet.
- A 9.8 in a mainstream MCP implementation, confirmed on NVD. CVE-2026-30623 is command injection (CWE-77) in LiteLLM’s MCP server creation flow: it executes attacker-supplied command and args values from a JSON config with no validation.
- Confused deputy isn’t theoretical. CVE-2026-13341 in Kong’s Konnect MCP server (CVSS 7.4) lets an indirect prompt injection make the server execute API requests the caller never intended.
- A secondary blog’s broader claim didn’t hold up against NVD. One widely shared write-up described CVE-2026-30623 as a flaw in “every official MCP SDK.” NVD’s actual record scopes it to LiteLLM specifically, a reminder to verify vendor claims yourself before you test or report.
- Scope is genuinely unclear right now. Anthropic’s own bounty terms exclude its reference MCP servers and cover only the maintained SDKs, which means a vulnerability in a popular community MCP server may have nowhere obvious to go yet.
- Tool poisoning needs no CVE to be real. A malicious or compromised MCP server can return tool descriptions that instruct an agent to act against the user’s intent, a vulnerability class current CVE databases mostly don’t capture well.
MCP servers are a genuinely new attack surface, not a rebrand of API security, and the bug bounty ecosystem’s scope rules haven’t caught up to that yet.
The Model Context Protocol connects AI agents to tools, files, and APIs, and its own specification states plainly that it does not enforce security at the protocol level. That gap is where real, confirmed MCP server vulnerabilities live, not hypothetical ones. This guide to MCP server vulnerabilities covers the classes worth testing for, two real CVEs we verified directly against NVD rather than repeated from a blog, how to actually find these issues, and the honest state of where they currently fit in bug bounty scope.
We already cover the defender’s side of this in our MCP server security guide, lockdown controls for teams running MCP servers. This article is the opposite angle: what to actually test and report if you’re hunting, not deploying.
An MCP server sits in an unusual position: it’s a piece of infrastructure that an AI agent trusts by design, often with far less scrutiny than a human would apply to a new API integration. That trust relationship is exactly what makes MCP server vulnerabilities worth testing for.
Two verified, current CVEs make these MCP server vulnerabilities concrete rather than hypothetical. We checked both directly against NVD’s own record rather than relying on secondary write-ups, since one of them turned out to be described incorrectly by a popular blog post.
NVD’s record describes it exactly: “LiteLLM 1.18.10 contains a remote code execution vulnerability in its MCP server creation functionality. The application allows users to add MCP servers via a JSON configuration specifying arbitrary command and args values. LiteLLM executes these values on the host without validation.”
AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H.The lesson for a hunter testing for MCP server vulnerabilities: any feature that lets a user or admin configure how an MCP server is launched, especially a command plus arguments pattern, deserves the same scrutiny you’d give a classic OS command injection point. The fact that “MCP” is in the product name doesn’t make the underlying bug class new.
Kong’s own security advisory and NVD both describe this as an indirect prompt injection in the Kong Konnect MCP server, versions before 1.0.0, that causes the server to execute API requests the caller never intended.
AV:N/AC:L/PR:N/UI:R/S:C/C:H/I:N/A:N.
Beyond the two CVEs above, these are the recurring classes of MCP server vulnerabilities a bug hunter should actively probe for in any server in scope:
UserAPIKeyAuth() fallback in LiteLLM’s MCP implementation, the first MCP flaw CISA ever added to its KEV catalog. Test every MCP endpoint for the basics: is authentication actually enforced, or does a missing or malformed credential silently fall through to an authenticated default.
# Illustrative: a quick first pass checking whether an MCP endpoint
# actually enforces auth, versus silently accepting no credential.
curl -s -o /dev/null -w "no-auth: %{http_code}\n" https://target/mcp
curl -s -o /dev/null -w "bad-auth: %{http_code}\n" https://target/mcp \
-H "Authorization: Bearer not-a-real-token"A 200 on either line, where the server should require a valid credential, is the first signal worth digging into.
Be honest with yourself about this before you invest hours: scope for MCP server vulnerabilities is genuinely unsettled right now. Anthropic’s own reference-server security policy states its bounty applies “exclusively to the MCP SDKs maintained by Anthropic,” and that “bug bounties are not awarded for security vulnerabilities found in these reference servers.” That means a real vulnerability in a popular, widely-deployed reference implementation may have no paying home at Anthropic specifically, even though it’s a genuine risk.
This doesn’t mean MCP findings aren’t valuable. It means you need to check each individual program’s scope carefully, since the answer varies by vendor and isn’t standardized yet the way web app scope generally is. A finding in a vendor’s own MCP server, inside their product, is a much clearer fit than a finding in a shared open-source MCP server nobody specifically owns the bounty for.
A strong report on MCP server vulnerabilities needs a few things a typical web finding doesn’t:
So yeah, here’s the part where we talk about our own angle, clearly marked as that.
XHack’s agent supports MCP connections, so testing an MCP integration is part of the same workflow as testing any other tool surface, not a separate specialty you need a different product for. For the classes above specifically, the agent’s recon and exploit-development capabilities apply directly: tracing how a server handles configurable launch behavior, checking authentication on every discovered endpoint, and reading tool descriptions the same way the hunting methodology above describes doing manually.
The honest part. Agent behavior on the prompt injection and tool poisoning classes of MCP server vulnerabilities is genuinely hard to make fully deterministic, for any tool, including ours. You are still the one who confirms a finding is real and reproducible before you submit it, and our terms are explicit that AI output can be wrong.
If MCP testing is part of your bug bounty workflow already, our coverage of AI exploit development and agentic pentesting go deeper on the exploit-chaining side of this. Start the trial or book a free consultation if you want to see how it fits your specific targets.
The most common MCP server vulnerabilities, the ones worth prioritizing first, are command or argument injection in server launch configuration, indirect prompt injection leading to confused-deputy behavior, tool poisoning through malicious tool descriptions, authentication gaps on MCP endpoints, and credential exposure. Two of these are backed by specific, NVD-verified CVEs: CVE-2026-30623 (LiteLLM, command injection) and CVE-2026-13341 (Kong Konnect, confused deputy).
No. A secondary blog described it that way, but NVD’s own record scopes CVE-2026-30623 specifically to LiteLLM’s MCP server creation functionality, not a cross-SDK flaw. Verify a CVE’s actual scope against NVD before you test or report based on a blog’s framing.
It depends entirely on the program. Some vendors’ bounty programs cover vulnerabilities in their own MCP implementations clearly. Others, including Anthropic’s own reference-server policy, explicitly exclude certain MCP servers from the bounty and cover only specific maintained SDKs. Check each program’s scope individually before investing time.
Prompt injection is content steering an agent’s behavior, which can come from anywhere the agent reads untrusted content. Tool poisoning is a specific case of it: the MCP server’s own tool descriptions or metadata, which the agent is expected to trust by design, contain the malicious instructions.
Include the exact client and model you tested with, the full prompt or content sequence that triggers the behavior, and a specific unauthorized action as the impact, not a vague description of unexpected behavior. Agent behavior can vary by model, so precision in your reproduction steps is what gets a finding triaged instead of closed as unverifiable.
No. It shares some overlap, but MCP introduces specific new patterns like tool poisoning and prompt-injection-driven confused deputy behavior that don’t have a direct equivalent in traditional API security testing. Our MCP server security guide covers the defensive controls side if you’re securing a deployment rather than testing one.
MCP server vulnerabilities, as this guide has shown, are real, current, and confirmed by specific CVEs you can check against NVD yourself, not a speculative future risk category. CVE-2026-30623 and CVE-2026-13341 prove the bug classes are concrete: command injection in launch configuration, and confused deputy through indirect prompt injection.
What’s genuinely unsettled about MCP server vulnerabilities is scope and payout, not whether they’re real. Test the classes above, verify any vendor or blog claim against NVD yourself before you rely on it, document reproduction with the precision these findings need, and check each program’s actual scope before assuming a payout exists for what you found.
Categories
Related articles
