MCP Atlassian server lets tool callers exfiltrate arbitrary server-local files via unrestricted attachment upload paths
Undisclosed·mcp-atlassian (MCP server for Jira/Confluence, sooperset/mcp-atlassian)Fixed
The Jira and Confluence attachment-upload tools in the mcp-atlassian MCP server accepted caller-controlled file_path/file_paths arguments and opened them directly from the server's own filesystem before uploading the contents as an attachment, so any MCP client permitted to call the upload tool could make the server read an arbitrary server-local file and push it out to a remote Jira/Confluence site.
- Blast radius
- In documented HTTP/SSE or streamable-http multi-user deployments, an attacker needing only upload-tool permission (no shell or direct filesystem access) could exfiltrate any file readable by the MCP server process — app config, mounted cloud/service credentials, CI/CD tokens, other shared-volume data — as a Jira/Confluence attachment; the advisory does not name specific affected deployments or quantify how many installs were exposed.
- Root cause
- Upload handlers (AttachmentsMixin.upload_attachment / upload_attachments in both the Jira and Confluence code paths) treated caller-supplied path strings as trusted server-local paths, calling os.path.exists then open(file_path,'rb') with no allowlist, realpath confinement, or restriction based on whether the deployment was network-exposed/multi-user.
- How it was caught
- Found and responsibly disclosed by external security researcher junbyjun1238 via a proof-of-concept MCP tool call against a test Confluence instance, not discovered from an exploited production incident.
- What changed
- Patched in mcp-atlassian v0.22.0; maintainers' recommended mitigations include default-denying server-local path uploads on HTTP/SSE deployments, adding an explicit opt-in flag, enforcing an allowlisted upload root after realpath resolution, and rejecting file:// URLs and UNC path forms before any filesystem check.
Take-awayAny MCP tool parameter that resolves to a server-local filesystem path is an untrusted boundary in multi-user or network-exposed deployments — constrain it to an allowlisted directory and prefer client-supplied file blobs over server-local path strings.