Another week, another MCP tool vulnerability. CVE-2026-27825 is a critical unauthenticated remote code execution flaw in mcp-atlassian, the popular MCP server that connects AI agents to Jira and Confluence.

The attack is straightforward: a remote attacker can overwrite files like ~/.bashrc or ~/.ssh/authorized_keys on the host machine. No authentication required.

The Vulnerability

The download_attachment and download_content_attachments tools in mcp-atlassian accept attacker-supplied target paths and write files without any restrictions. No directory confinement. No path traversal validation. No symlink checks.

When the MCP HTTP transport is exposed (often bound to 0.0.0.0 with no authentication — a disturbingly common configuration), any remote attacker can:

  1. Craft a request with a path like ../../.ssh/authorized_keys
  2. The tool writes the file wherever the path points
  3. The attacker now has SSH access to your machine

A companion SSRF vulnerability (CVE-2026-27826) was disclosed alongside it. Middleware in the same package honors X-Atlassian-Jira-Url and X-Atlassian-Confluence-Url headers without validation, enabling server-side request forgery to arbitrary destinations from the victim host.

The Pattern

This is the third major MCP vulnerability in recent weeks:

  • CVE-2025-59536 / CVE-2026-21852 — Claude Code MCP consent bypass and API key exfiltration via malicious repo config
  • CVE-2026-27825 / CVE-2026-27826 — mcp-atlassian RCE and SSRF via unvalidated paths and headers
  • Ongoing discovery of similar issues across the MCP ecosystem

The pattern is consistent: MCP tools that bridge AI agents to external services often lack basic security primitives that we solved decades ago in web development. Path traversal, input validation, authentication — these aren’t novel attack classes.

Why MCP Tools Are Uniquely Risky

Traditional software tools have clear input boundaries. MCP tools don’t:

  1. Agent-driven inputs: The AI model decides which parameters to send, based on context that may include attacker-controlled data (documents, emails, chat messages)
  2. Trust assumptions: MCP servers often assume they’re behind a trusted boundary, but HTTP transport on 0.0.0.0 breaks that assumption
  3. File system access: Many MCP tools write files as a core function, making path traversal a feature-adjacent vulnerability
  4. No sandboxing standard: Unlike browser extensions or mobile apps, MCP servers have no mandatory permission model

Mitigation

Immediate: Upgrade mcp-atlassian to version 0.17.0 or later.

Structural:

  • Never bind MCP HTTP transport to 0.0.0.0 — use localhost only
  • Add authentication to any MCP server exposed over HTTP
  • Audit file write paths in every MCP tool you use
  • Run MCP servers in containers to limit blast radius
  • Review the MCP tools your agent has access to — each one is an attack surface

OpenClaw Implications

OpenClaw users connecting to MCP servers should treat every MCP tool as a potential attack vector until audited. The framework’s permission model can restrict which tools an agent can call, but it can’t fix vulnerabilities inside the MCP server itself.

Practical steps:

  1. Inventory your MCP servers — list every one your agent connects to
  2. Check versions — look for CVE disclosures on each
  3. Network isolation — MCP servers should only be reachable from localhost
  4. Least privilege — only grant your agent the MCP tools it actually needs
  5. Monitor file writes — watch for unexpected file creation outside expected directories

Arctic Wolf reports no active exploitation yet, but a public proof-of-concept exists. Given Atlassian’s popularity as a target and the trivial exploitation path, this will likely be weaponized.

Update now. Audit your MCP server configurations. The agent ecosystem’s security posture depends on every tool in the chain, not just the framework.

Related: Claude Code MCP supply chain vulnerabilities, PleaseFix agentic browser hijacking, and our complete guide to OpenClaw security.