mcp-atlassian Unauthenticated SSRF and Path Traversal to Root RCE - CVE-2026-27825

CVE-2026-27825, nicknamed MCPwnfluence, is a critical unauthenticated SSRF-to-RCE chain in mcp-atlassian, the most widely used Atlassian MCP server with more than 4 million downloads. The mcp-atlassian RCE turns two unauthenticated HTTP requests into code execution as root on any reachable instance. This advisory covers what was disclosed, why it lands on the agentic-endpoint layer, and how to inventory and govern it across your fleet - one of the eight AI artifact types Anomity tracks.

What happened

mcp-atlassian exposes its tools over an MCP HTTP transport that is often bound to 0.0.0.0 with no authentication. Two of those tools - download_attachment and download_content_attachments - accept an attacker-supplied target path and write files without confining them to a safe base directory and without checking for path traversal or symlinks. On its own, that is an arbitrary file write. Combined with a middleware SSRF that lets an attacker bypass the trust boundary in front of the transport, it becomes a remote, unauthenticated primitive.

From there the path to code execution is short. An attacker uses the arbitrary file write to overwrite files such as ~/.bashrc or ~/.ssh/authorized_keys, establishing persistence or direct execution. Researchers demonstrated that anyone on the same local network can run code as root with two unauthenticated HTTP requests. All mcp-atlassian versions below 0.17.0 are affected, with network-exposed deployments at highest risk. The fix in 0.17.0 adds safe path validation and SSRF protections including optional domain allowlisting, and the issue was resolved on February 24, 2026.

The shape is familiar. An MCP server binds a network transport with no auth, a tool trusts input it should validate, and the gap becomes unauthenticated code execution - the same pattern documented in the MCP STDIO execution-by-design class and tracked across the 2026 MCP CVE wave. What is specific here is the write-capable download tools and a 4-million-download install base.

Why this is an agentic-endpoint risk

An MCP server is not a passive dependency. mcp-atlassian is code an AI agent invokes to read and write Jira and Confluence, running with the agent's privileges on a managed endpoint. Because the SSRF lifts the trust boundary and the download tools write to arbitrary paths, a single exposed instance hands an attacker the host - not just the agent's Atlassian data.

The exposure is hard to see from the controls you already run, because it lives in the AI artifact layer. A developer installs mcp-atlassian to connect an agent to a project board; the HTTP transport binds to 0.0.0.0 to make a container reachable; the process looks legitimate to EDR; the network sees ordinary agent traffic; and DLP sees nothing at rest. MCP servers are adopted bottom-up and report to no security tool - the dynamic that makes AI agents and MCP servers the new shadow IT. The question is not whether mcp-atlassian is documented; it is which endpoints run it, on which version, and with which transport - and you cannot answer that without an inventory of the artifact layer.

How Anomity surfaces and governs it

Upgrading to 0.17.0 patches the endpoints you can see. Anomity's job is to find every instance, govern the write-capable tool calls at the hook, and keep the record - in three steps.

First, inventory. Anomity inventories every MCP server on every managed endpoint as part of the eight AI artifact types it tracks, capturing configuration metadata - the installed package and version, the transport and bind address, and the agent that launches it. It classifies each server by trust signals and infers the capabilities it grants, so an mcp-atlassian instance below 0.17.0 bound to 0.0.0.0 surfaces as a match. Metadata only: secrets are redacted on the endpoint before anything leaves it.

Second, decide at the hook. On agents that expose a hook - for example, the PreToolUse event in Claude Code - Anomity evaluates each tool call against your policy and returns allow, deny, or log before the call runs. A call to a write-capable tool such as download_attachment or download_content_attachments targeting a path outside an expected directory can be denied at the boundary instead of executing, which is exactly the control runtime governance provides while you roll out the patched version.

Third, keep the record. Every decision, and every added, changed, or removed MCP server, lands in a queryable 90-day audit trail, and decisions route to SIEM, Slack, email, or Jira. When a CVE like CVE-2026-27825 is published, you can answer where mcp-atlassian runs, which version, what it was allowed to do, and what it did - from a record, not a guess. Anomity complements your Network, EDR, DLP, and GRC tooling; it covers the artifact layer those tools were never built to inventory.

You can't govern what you can't see.The Anomity principle

What to check across your fleet

• Inventory every endpoint running mcp-atlassian and record the exact version - flag anything below 0.17.0 as in-scope for CVE-2026-27825.
• Identify any mcp-atlassian HTTP transport bound to 0.0.0.0 or otherwise network-reachable without authentication, and treat those as highest risk.
• Confirm the download_attachment and download_content_attachments tool calls are evaluated at the agent hook with allow/deny/log, so a traversal or symlink write is stopped before it runs.
• Check for tampering signatures of the chain - unexpected changes to ~/.bashrc, ~/.ssh/authorized_keys, or other startup and trust files on hosts that ran an exposed instance.
• Prioritize upgrading every instance to 0.17.0 or later and enable the optional domain allowlisting the fix adds; track the rollout against your inventory, not a spreadsheet.
• Verify that every server change and every governed tool call is written to a 90-day audit trail and routed to your SIEM, so the next CVE in this class is a lookup.

CVE-2026-27825 is patchable - 0.17.0 closes the chain - but only on the mcp-atlassian instances you can actually see, and a 4-million-download tool installed bottom-up rarely sits in one inventory. The way through is to inventory every MCP server, govern write-capable tool calls at the hook, and keep a queryable record. For the full attack surface, trust tiers, and the 2026 CVE wave this advisory sits in, see the pillar guide on MCP server security. To see Anomity inventory and govern the MCP layer across your fleet, request early access.