AI assistants wired to external tools and data are rapidly reshaping how organizations automate work — and recent disclosures show those same integrations can become high‑leverage attack rails when MCP servers are left unsecured.
A Model Context Protocol (MCP) server is the runtime bridge that exposes tools, resources, and data to an LLM-driven assistant. In practical terms, an MCP server exposes a set of discrete capabilities — for example, “read this file,” “run a git command,” or “convert an HTML page to Markdown” — so an AI agent can invoke them as structured tools during a conversation or automated task. These servers are now being used across IDE plugins, CI tooling, cloud automation, and developer utilities because they make it straightforward to let models perform real-world actions. The design trade-off is obvious: empowerment for the model equals more sensitive privileges for code that is often running on developer workstations or cloud compute instances. That surface area includes filesystem access, network fetches, and interaction with OS‑level utilities — all of which magnify the consequences of insecure implementations. Recent research findings and vendor advisories show that several popular MCP reference implementations contained design and coding errors that could be chained into severe outcomes including arbitrary file access, cloud credential theft, and remote code execution (RCE).
Because agents ingest content from external sources, adversaries can weaponize those inputs. That means security engineering for agent ecosystems must operate at the intersection of application security, cloud configuration, and model governance — a multidisciplinary remit that combines hardening, telemetry, and governance policy. The technical controls required are familiar — input validation, canonical path resolution, least privilege, and IAM hygiene — but they must be applied with the recognition that assistant actions are not purely local: they translate natural language into a sequence of tool calls that, when combined, can cross trust boundaries.
In practice, that means urgent patching, limited and audited capability exposure, IMDSv2 adoption in cloud environments, and an operational assumption that any tool input is untrusted. When those steps are followed, MCP servers can deliver their productivity benefits without becoming the next high‑value gateway for cloud or RCE attacks.
Source: Petri IT Knowledgebase Critical MCP Flaws Turn AI Assistants Into Cloud and RCE Attack Vectors
Background: what is an MCP server and why it matters
A Model Context Protocol (MCP) server is the runtime bridge that exposes tools, resources, and data to an LLM-driven assistant. In practical terms, an MCP server exposes a set of discrete capabilities — for example, “read this file,” “run a git command,” or “convert an HTML page to Markdown” — so an AI agent can invoke them as structured tools during a conversation or automated task. These servers are now being used across IDE plugins, CI tooling, cloud automation, and developer utilities because they make it straightforward to let models perform real-world actions. The design trade-off is obvious: empowerment for the model equals more sensitive privileges for code that is often running on developer workstations or cloud compute instances. That surface area includes filesystem access, network fetches, and interaction with OS‑level utilities — all of which magnify the consequences of insecure implementations. Recent research findings and vendor advisories show that several popular MCP reference implementations contained design and coding errors that could be chained into severe outcomes including arbitrary file access, cloud credential theft, and remote code execution (RCE). The disclosures: two headline problems, many derivatives
Anthropic’s Git MCP server — prompt injection → file writes → RCE
Security researchers disclosed three related vulnerabilities in Anthropic’s official Git MCP server implementation. The three issues — tracked as CVE‑2025‑68143, CVE‑2025‑68144, and CVE‑2025‑68145 — together allowed attackers to:- Create or manipulate Git repositories in arbitrary filesystem locations (a git_init weakness).
- Bypass repository-path validation so tool calls could operate outside the intended repository boundary.
- Pass unsanitized, user‑controlled arguments into Git operations, enabling flag injection and file overwrites.
- The git_init tool accepted arbitrary paths, allowing repo creation anywhere the server process had write permission; Anthropic removed or disabled that tool in fixes.
- Path validation for the configured repository flag did not prevent subsequent tool calls from specifying repo paths outside the intended directory; fixes added canonical path resolution and checks.
- Git argument handling failed to reject “flag-like” inputs (values starting with “-”), enabling argument injection; mitigations added explicit checks and validation against real git refs.
Microsoft MarkItDown MCP server — unbounded URI fetch → SSRF → cloud token theft
A separate disclosure by BlueRock identified a Server‑Side Request Forgery (SSRF) class issue (dubbed MCP fURI) in Microsoft’s MarkItDown MCP server. The tool in question (convert_to_markdown) accepted arbitrary URIs without proper bounding, enabling any caller to instruct the MCP server to fetch arbitrary HTTP or file resources. When that server runs on an AWS EC2 instance configured to allow IMDSv1 metadata access, a crafted URI can be used to fetch instance metadata (169.254.169.254), extract IAM role credentials, and escalate to the cloud account depending on role privileges. BlueRock’s analysis of more than 7,000 MCP servers showed a worrying prevalence of unbounded fetch handlers across the ecosystem. BlueRock’s testing showed the problem is systemic: many reference servers and third‑party implementations expose similar “fetch any URI” semantics, and the ecosystem has been quick to reuse canonical servers (e.g., MarkItDown, Git MCP) as templates. That combination of reuse and permissive defaults multiplies risk across hundreds or thousands of deployments. BlueRock also provided mitigation guidance including blocking access to metadata endpoints, enforcing stdio-only MCP transports, and adding URI allowlists or safe resolvers.Why these aren't mere implementation bugs — they reveal architectural risks
The security failings documented here fall into two layers: coding errors (missing validation, unsafe argument passing) and architectural trust assumptions (design that implicitly trusts the model or callers). Both layers are meaningful.- Coding issues are actionable and patchable: sanitize inputs, canonicalize paths, and reject flag‑like arguments. The Git MCP fixes primarily address these defects.
- Architectural assumptions are harder: MCP servers are often built with the expectation that the “agent” or “user” invoking tools is cooperative and limited. But agents are non‑deterministic and can be influenced by external content; prompt injection is now a practical exploitation primitive when the assistant is granted wide privileges. That means a design that gives tools filesystem or network access without provenance, permissioning, or scoping is fundamentally fragile.
The cloud angle: IMDSv1, IMDSv2, and why SSRF still matters
A central cloud risk in the MarkItDown SSRF findings is the AWS Instance Metadata Service (IMDS). Historically, IMDSv1 accepted unauthenticated GET requests to the link‑local address 169.254.169.254 and returned temporary credentials attached to the instance role. Attackers leveraged SSRF to fetch those credentials in high‑profile incidents; IMDSv2 was introduced to add a session token requirement (a PUT to obtain a token) and reduce SSRF attackability. AWS recommends migrating to IMDSv2 and disabling IMDSv1 where possible to reduce SSRF exposure. However, reality is mixed: many cloud images, orchestration stacks, and custom toolchains still permit IMDSv1, and attacker techniques (including DNS rebinding, proxy chaining, or local compromise) can be effective when metadata access is permissive. BlueRock’s point is pragmatic: an MCP server that will fetch arbitrary URIs should not be making any unbounded HTTP requests from hosts that might expose sensitive internal endpoints, and operators should treat metadata endpoints as sacrosanct. AWS guidance is to:- Prefer IMDSv2 and configure instances with HttpTokens=required.
- Use IAM least privilege for instance profiles and enforce usage conditions where possible.
- Monitor and migrate existing workloads using available tools and AWS Config rules (for example, ec2‑imdsv2‑check).
How defenders should prioritize — practical, concrete steps
The disclosures illustrate a pattern common to emergent agent ecosystems: convenience features expose high‑value primitives unless deliberateely constrained. The following prioritized steps are designed for security teams, platform engineers, and operations staff to materially reduce MCP risk.1. Immediate triage (hours)
- Inventory MCP servers and agent endpoints across the estate — where are MCP binaries running and which ports/transports are enabled? Start with known reference servers (mcp-server-git, MarkItDown) and hosted agent endpoints.
- If you run MarkItDown or other fetch‑capable servers, block outbound network access for those hosts until you can ensure safe URI handling. BlueRock suggests restricting HTTP access and binding servers to localhost or stdio-only transports where appropriate.
- Ensure all EC2 instances running MCP servers enforce IMDSv2-only (set HttpTokens=required) or otherwise prevent IMDSv1 access; rotate any potentially exposed credentials.
2. Near-term remediation (days)
- Patch and upgrade: apply the fixes for mcp-server-git and other reference packages immediately. The Anthropic Git fixes were published in releases noted in advisories; upgrade to the patched versions (those advisories reference versions patched in late 2025).
- Apply network egress controls and metadata protections: enforce VPC/NACL/WAF rules that prevent application services from requesting internal metadata endpoints. Where possible, enforce network allowlists for MCP hosts.
- Treat tool inputs as untrusted: enforce strict input validation for any MCP tool that takes filesystem paths or URIs. Reject any values that start with “-” for git ref parameters, canonicalize paths and require that git operations resolve within the configured repository boundary.
3. Medium‑term architectural controls (weeks to months)
- Reduce blast radius by limiting the set of MCP tools available to an agent. Use capability whitelists and avoid bundling filesystem, network‑fetch, and code‑execution tools in the same agent profile.
- Introduce provenance and policy enforcement: require that MCP server calls include a verifiable token describing the request origin (human, automation pipeline, or model), and enforce role‑based constraints on which callers can use which tools.
- Introduce semantic DLP and conversational provenance controls that treat assistant requests like API calls: record, audit, and allow conditional redaction for sensitive operations initiated by the assistant. This is important because many attacks exploit content (malicious prompts) rather than network bugs.
4. Recovery and hardening playbook (for incident response)
- If indicators suggest MCP-based compromise, isolate the host, preserve logs and tool invocation histories, and rotate all instance and service credentials associated with the host. Treat the instance as fully compromised if IMDSv1 was exposed.
- Hunt for signs of chained actions: unexpected .git/config modifications, unknown clean/smudge filters, creation of shell scripts in writable directories, and surprising outbound connections to internal metadata addresses.
Strengths of the community response — and remaining risk
The disclosures illustrate healthy responsible disclosure and community response at work. Researchers from multiple firms coordinated to produce detailed technical writeups. Anthropic published fixes to the reference Git MCP server, and BlueRock shared detection and mitigation patterns. Coverage from multiple independent outlets and advisory databases means operators have both the technical details and the explicit fix versions to act on. Nevertheless, notable risks remain:- Ecosystem replication: MCP reference implementations are reused as templates. A patched reference server reduces but does not eliminate risk because many third‑party servers may have copied insecure logic before fixes were released.
- Composition hazards: many attacks require chaining — a Filesystem MCP server plus a Git MCP server plus a permissive prompt can still yield RCE even if some components are patched or hardened. This means defenders must assume composability when modeling risk.
- Cloud drift: IMDSv1 remains present in many environments and transition to IMDSv2 can be operationally non‑trivial. Until migration is complete, SSRF remains a plausible escalation method for attackers.
Checklist: immediate actions for Windows and cloud teams
- Patch mcp-server-git and other MCP servers to the versions identified in vendor advisories. Confirm versions via your package manager or GitHub releases.
- For any MCP server that performs URI fetches, add request‑scoped allowlists and deny requests to 169.254.169.254 and other internal metadata addresses.
- Configure EC2 instances to require IMDSv2 (HttpTokens=required) and monitor IMDSv1 usage with AWS Config and CloudWatch metrics. Rotate roles and credentials if an instance’s IMDSv1 calls were observed.
- Limit the runtime privileges of MCP processes (run as unprivileged users, isolated containers, or in separate network namespaces) and avoid running MCP servers as root or administrator.
- Revisit your agent profiles: separate dangerous capabilities (filesystem write, system exec, network fetch) into distinct, auditable profiles and apply least privilege to each.
The strategic lesson for agentized operations
MCP servers are a potent productivity multiplier — and the same properties that make them useful (programmatic access to files, code, and the network) make them powerful attack primitives when misconfigured. The line between convenience and vulnerability is drawn by assumptions: assumptions about who or what will call an MCP, what inputs are trusted, and which resources should be reachable.Because agents ingest content from external sources, adversaries can weaponize those inputs. That means security engineering for agent ecosystems must operate at the intersection of application security, cloud configuration, and model governance — a multidisciplinary remit that combines hardening, telemetry, and governance policy. The technical controls required are familiar — input validation, canonical path resolution, least privilege, and IAM hygiene — but they must be applied with the recognition that assistant actions are not purely local: they translate natural language into a sequence of tool calls that, when combined, can cross trust boundaries.
Conclusion
The recent MCP disclosures are a valuable wake‑up call. They demonstrate how an assistant’s capabilities turn into an attacker’s capabilities whenever the tool boundary is porous. The fixes issued by vendors and the mitigation guidance offered by researchers are effective — if acted on promptly — but they do not absolve organizations from a deeper responsibility: to design and operate agentic systems with explicit, layered controls around who or what can ask the assistant to act and what the assistant is allowed to do.In practice, that means urgent patching, limited and audited capability exposure, IMDSv2 adoption in cloud environments, and an operational assumption that any tool input is untrusted. When those steps are followed, MCP servers can deliver their productivity benefits without becoming the next high‑value gateway for cloud or RCE attacks.
Source: Petri IT Knowledgebase Critical MCP Flaws Turn AI Assistants Into Cloud and RCE Attack Vectors
