Safe locally, exposed when shared

mcp-atlassian exposes Jira and Confluence to an AI agent as tools it can call. It speaks two transports: stdio, for a single local user, and Streamable HTTP, for the shared multi-user deployments teams run. Two of its features are harmless under the first and become a security boundary under the second.

Restricting Tool Access

Operators scope an HTTP deployment with ENABLED_TOOLS or TOOLSETS, exposing only the tools they mean to allow. It reads like an allowlist.

Those filters are meant to stop restricted tools from being called. They only hide them from the menu: the filtering runs when the server answers tools/list. Call tools/call with a restricted tool's name and it executes anyway, from the full inventory (73 tools at the time of testing), no check. Every write and delete on Jira issues, Confluence pages, and sprints is one direct call away.

READ_ONLY_MODE, a similar control, does it right, enforced at both tools/list and tools/call.

Rated High (8.8). Full details in the advisory: GHSA-3r68-hf9h-887v.

Reading and Exfiltrating Server Files

The attachment-upload tools, confluence_upload_attachment and jira_update_issue, take a file_path and open it. Under stdio that path is your own file. Over HTTP it resolves on the server's filesystem, not the caller's.

So a client can point file_path at any file the server can read. The tool reads it, uploads it to Atlassian as an attachment, and the same session downloads it straight back. This path traversal runs entirely at runtime, over the agent's own tool calls, and exfiltrates whatever the server holds, its config, its stored OAuth tokens, the API credentials in its environment, straight out to the attacker.

Rated High (7.7). Full details: GHSA-wm45-qh3g-v83f.

The "restricted" deployment that restricted nothing

Picture a team hardening mcp-atlassian for a shared HTTP deployment. They set ENABLED_TOOLS to a small read-only Jira subset. Attachment upload is not on the list, so as far as they know, it's off the table.

It isn't.

1. Bug 1: a caller invokes confluence_upload_attachment anyway, the tool the operator thought they'd disabled.

2. Bug 2: that upload reads the server's environment and hands it back as a downloadable attachment.

3. Out come the Atlassian API tokens, and with them the attacker hits the REST API directly, no server, no ENABLED_TOOLS, nothing in the way.

A least-privilege deployment ends up handing over the keys to its own backend, every control still in place, none of it in the path.

Upgrade to v0.22.0

These flaws affect mcp-atlassian versions prior to 0.22.0.

After we responsibly reported the findings to the maintainer (@sooperset), both bugs are fixed in mcp-atlassian 0.22.0, which users should upgrade to. We thank the maintainer for coordinating and releasing the fixes through GitHub's advisory process. CVEs have been requested and will be assigned to the advisories in the near future.

Although this is an OSS project from an independent maintainer, we gave Atlassian a courtesy heads-up prior to publishing, given the possible usage of mcp-atlassian across the wider Atlassian community and its developers, which Atlassian thanked us for.

How Manifold can help

AI agents act with real authority. They call tools, move data, and make decisions with the credentials you have handed them, and the controls meant to keep that authority in check usually live one layer above where the action actually happens.

That is a layer most tooling never sees. Your EDR sees a process making ordinary API calls. Your gateway sees authenticated HTTPS to a service you allow. Neither sees what the agent is actually doing with the access it holds. Manifold watches that layer: what AI agents and MCP servers actually do at runtime, not what their configuration says they can.