MCP Atlassian 0.22 Closes a 37-Advisory Security Audit

2026-07-14 AI CVEs by al-ice.ai Editorial

The maintainers of mcp-atlassian, an MCP server that connects AI clients to Jira and Confluence, have released a coordinated security hardening update. Version 0.22.0, published July 10, says it resolves 37 advisories consolidated into root-cause families across attachment handling, HTTP authentication, server-side request forgery, tool authorization, project and space filters, OAuth token storage, and reflected XSS. Version 0.22.1 followed on July 11 with additional SSRF and filtering corrections.

This is not simply a long list of independent CVEs. Several reports overlap around the same sinks and deployment boundaries. The release is still operationally significant because the affected component sits between untrusted model context and high-value collaboration data, while remote deployments also expose a server process, filesystem, credentials, and outbound network path.

Attachment tools crossed the client-server boundary

Two public GitHub advisories describe overlapping arbitrary-file-read reports in the Jira and Confluence attachment paths. Before 0.22.0, client-supplied file_path values could reach open() on the MCP server without confinement to an approved workspace. A client able to invoke the relevant tools could make the server upload readable local files into Atlassian, creating an exfiltration channel.

The clearest affected boundary is a remote or multi-user HTTP deployment. A caller may reasonably think a path refers to its own machine, but the MCP tool resolves that path on the server. The advisory demonstrates reads of files such as /etc/passwd and /proc/self/environ; the latter can contain Jira, Confluence, cloud, database, or other process credentials. In a local single-user stdio deployment, reading the user's local path is the intended attachment behavior, so the same operation does not necessarily cross a separate trust boundary.

GitHub rates the broad attachment-upload advisory High, CVSS 3.1 7.7 and lists versions earlier than 0.22.0 as vulnerable. The 0.22.0 release confines caller-supplied paths with validate_safe_path, applies the control to Jira and Confluence upload and download paths, and adds an in-memory content_base64 input so remote clients do not need to refer to the server filesystem.

Prompt injection turns a tool flaw into a remote path

One overlapping advisory reports an end-to-end test in which a prompt embedded in a Jira ticket induced an AI agent to call the vulnerable Confluence upload tool with /proc/self/environ. That scenario is not the same as a universally unauthenticated network exploit: it requires an agent that reads attacker-controlled content, has the affected MCP tool available, and follows the injected instruction. But it illustrates why agent-facing tool authorization must account for model manipulation rather than treating possession of an MCP session as proof of operator intent.

The release addresses that wider control plane too. It says tools hidden by ENABLED_TOOLS, toolsets, or read-only mode are now checked at dispatch rather than merely omitted from tool listings. It also changes remote HTTP authentication so unauthenticated requests no longer inherit operator-global Atlassian credentials by default; the old fallback is now an explicit ALLOW_GLOBAL_CRED_FALLBACK opt-in. Defenders should treat that compatibility switch as a deliberate exception, not a routine migration shortcut.

The first SSRF patch still re-resolved DNS

GHSA-489g-7rxv-6c8q documents an incomplete fix for the earlier X-Atlassian-Jira-Url and X-Atlassian-Confluence-Url SSRF issue associated with CVE-2026-27826, covered in the site's original mcp-atlassian RCE and SSRF briefing. The guard resolved an attacker-controlled hostname once and rejected non-global addresses, but later built the outbound request with the original hostname. A second DNS resolution at connection time could therefore return a cloud metadata or internal-service address after validation had passed.

The public advisory is careful about exploitability: its proof demonstrates the time-of-check/time-of-use structure, not a live end-to-end compromise. Exploitation additionally requires attacker-controlled rebinding DNS and success in the resolve-to-connect window. GitHub rates this sibling advisory Medium, CVSS 3.1 6.5; versions before 0.22.0 are affected.

Version 0.22.0 adds a DNS-pinning transport adapter so validation and connection use the same address. The 0.22.1 follow-up then keeps caller-controlled destinations on that direct pinned path even when deployment proxies are configured, because proxy-side resolution could otherwise reopen the gap. Operator-configured Jira, Confluence, OAuth gateway, and explicitly allowlisted hosts retain proxy support. That distinction matters in proxy-only environments: an untrusted destination may now fail closed rather than remain reachable through the proxy.

Defensive engineering guidance

Upgrade to at least 0.22.1. Version 0.22.0 establishes the main security boundary, but 0.22.1 includes relevant follow-up fixes for proxy-aware DNS pinning, redirects, and Jira project filtering. Rebuild containers and restart long-running MCP processes after updating.
Inventory the transport, not just the package. Identify streamable-http and SSE deployments, their bind addresses, authenticating reverse proxies, tenant model, service account, workspace directory, and outbound proxy behavior. The file-read impact is materially different from local stdio.
Rotate secrets when exposure was plausible. If an affected remote server accepted untrusted clients or agent-driven tool calls, review Atlassian attachment history and MCP logs, then rotate process-environment credentials, Atlassian tokens, cloud keys, and other readable secrets as warranted.
Keep global credential fallback disabled. Require per-user authentication and authorization at the HTTP boundary. Test unauthenticated requests and malformed authorization headers and verify they fail before any tool dispatch.
Constrain tools at execution. Expose only required Jira and Confluence operations, preserve read-only mode where possible, and verify disabled tools cannot be invoked by name. Add approval for attachment writes and other data-moving actions.
Model prompt injection as a caller. Treat Jira issues, comments, Confluence pages, and attachments as untrusted instructions. Do not allow their contents alone to authorize filesystem reads, credential access, uploads, or writes.
Test SSRF controls through real egress paths. Include redirects, DNS rebinding, configured proxies, private addresses, metadata endpoints, IPv6, and allowlisted on-premises hosts. Validation that does not bind the checked address to the socket is incomplete.

The coordinated patch is a useful case study in MCP security architecture. Path validation fixes the immediate file sink, but durable protection also requires authenticated transport, dispatch-time authorization, least-privilege credentials, safe data-transfer semantics, and outbound connections that preserve the result of SSRF validation. Agent security fails when any one of those boundaries exists only in the model's tool description.

Sources: