Claude Code MCP security vulnerabilities refer to the class of attack surfaces created when Anthropic's Claude Code command-line assistant connects to external services via Model Context Protocol. MCP lets AI tools like Claude Code read files, query databases, and execute commands — which means a misconfigured or compromised MCP server becomes a direct path into your infrastructure.

Why Claude Code's MCP Integrations Are a Security Problem Right Now

Claude Code is being adopted fast. Developers are wiring it up to internal tools, databases, and third-party services through MCP connections — often without security review. The protocol is designed for flexibility, which is useful, but flexibility without guardrails is a liability.

The concern isn't theoretical. According to CSO Online's June 2026 reporting, Claude Code has an MCP security problem and developers are already using it at scale. The attack surface exists whether or not your security team knows MCP is in play.

The core issue: MCP gives Claude Code the ability to act on external systems. That's the whole point. But when those connections aren't inventoried, restricted, or monitored, you're essentially handing an AI assistant a set of keys you haven't audited.

What the Flowise Vulnerability Tells Us About MCP Risk More Broadly

The Flowise case is instructive even if you're not running Flowise. Researchers at Obsidian Security documented a 9.9-severity vulnerability in Flowise's MCP stdio implementation that allows remote code execution in self-hosted deployments. The vulnerability lets attackers run ghost commands through the MCP stdio transport layer.

This matters for Claude Code teams for one reason: the attack pattern is about the MCP implementation, not just the specific product. Any tool using MCP stdio transport without proper input sanitization and authentication controls is exposed to similar logic. If your Claude Code setup is connecting to self-hosted MCP servers — internal tools, local databases, custom integrations — you need to audit how those servers handle incoming instructions.

The stdio transport is particularly risky because it runs locally with whatever privileges the host process has. That often means elevated access to the filesystem, environment variables, and network interfaces.

The Specific Vectors to Audit in Claude Code Deployments

Here's what to look at when reviewing how your team has Claude Code wired up:

MCP server inventory: Do you actually know every MCP server Claude Code is connecting to? Most teams don't have a list. Start there.
Authentication on MCP servers: Are your internal MCP servers requiring authentication, or will they respond to any connection that arrives on the right port?
Privilege scoping: What can each MCP server actually do? Read-only connections for data lookups should never have write or execute permissions.
Prompt injection paths: MCP servers that pull content from external sources — emails, tickets, web pages — can carry injected instructions that Claude Code will act on. This is a real attack vector, not a hypothetical.
Logging and audit trails: Can you replay what Claude Code did through an MCP connection last Tuesday? If not, you have no forensic capability.
Network exposure: Are your MCP servers accessible beyond localhost? If so, why, and what's protecting them?

How Enterprise Deployment Changes the Risk Profile

As organizations like KDDI Agile Development Center roll out Claude Enterprise across their workforce, the governance gap between "developer experiment" and "production deployment" becomes acute. Anthropic's enterprise model includes controls at the account and policy level, but MCP security is largely the customer's responsibility to configure and enforce.

That division of responsibility is where things fall apart. Developers assume the platform handles security. Security teams assume developers have configured integrations safely. Neither group has a clear owner for MCP server hygiene.

The enterprises getting this right are treating MCP connections the same way they treat API integrations: with a formal review process, documented permissions, and monitoring in place before developers start wiring things up.

What a Minimum Viable MCP Security Policy Looks Like

You don't need a 40-page document. You need answers to these questions, enforced consistently:

Control	What it covers	Who owns it
MCP server allowlist	Only approved servers can be connected	Platform/security team
Auth requirements	All MCP servers require token or cert auth	Engineering
Permission scoping	Read vs. write vs. execute per server	Engineering + security review
Prompt injection monitoring	Flag responses that contain instruction-like content	Security
Audit logging	Log all MCP calls with timestamps and payloads	Platform team
Incident response playbook	What happens when an MCP call looks anomalous	Security

Prompt Injection Through MCP Is the Underrated Risk

Most conversations about MCP security focus on server vulnerabilities and network exposure. The more insidious risk is prompt injection through MCP-connected data sources.

Here's the attack: a malicious actor puts an instruction inside a document, ticket, or email that Claude Code reads through an MCP connection. Claude Code processes the content and the embedded instruction gets treated as a legitimate command. This could mean exfiltrating data, calling additional tools, or modifying files — all triggered by something that looks like ordinary content.

This isn't a bug in Claude Code specifically. It's a fundamental challenge with language models that take action based on retrieved content. The defenses are architectural: separate retrieval from execution, treat retrieved content as untrusted by default, and have Claude Code operate under least-privilege constraints so that even a successful injection can't do much damage.

What Teams Are Getting Wrong When They Deploy Claude Code with MCP

The most common mistakes aren't exotic. They're the same governance failures that showed up with cloud storage in 2015 and API keys in 2019:

Spinning up MCP integrations in development environments that later get promoted to production without security review
Using the same MCP server connection with the same broad permissions across multiple Claude Code users
No logging, so there's no way to know what happened if something goes wrong
Treating "it's just a dev tool" as a reason not to apply production security standards — when the tool has access to production data

Claude Code is a command-line tool that developers are adopting fast, as CSO Online noted in their June 2026 coverage. Speed of adoption and security review cycles rarely move at the same pace. The gap between the two is where incidents happen.

The Practical Starting Point

If you're running Claude Code with MCP integrations today and haven't done a security review, start with discovery. List every MCP server connection in your environment, document what permissions each one has, and flag any that are exposed beyond localhost or that lack authentication.

That inventory takes a few hours. What comes next — tightening permissions, adding logging, building a review process — takes longer, but you can't prioritize what you haven't found yet.

MCP is a genuinely useful protocol. It's also a new attack surface that most security teams haven't caught up to. The window between "developers are using this" and "security team knows about it" is exactly where the risk lives right now.