MCP Atlassian server let agents exfiltrate arbitrary local files via unvalidated upload_attachment path
Undisclosed·mcp-atlassian (sooperset/mcp-atlassian MCP server for Jira/Confluence)Fixed
The upload_attachment method in mcp-atlassian's Confluence integration read a caller-supplied local file path and uploaded it as a page attachment without ever calling the project's own validate_safe_path() check, so an AI agent connected via MCP — including one manipulated through prompt injection — could be directed to read arbitrary local files (e.g. /etc/passwd, SSH keys, .env files) and upload them to a Confluence page as an attachment.
- Blast radius
- Any file readable by the MCP server process could be exfiltrated to a remote Confluence instance viewable by other users; the download methods in the same file were already protected by validate_safe_path(), so only the upload path was exposed. Affects all mcp-atlassian deployments prior to version 0.22.0; no specific victim organisation or breach is named in the advisory.
- Root cause
- validate_safe_path() was implemented and used consistently in the download_attachment and download_content_attachments methods but was never added to the newer upload_attachment code path, leaving an asymmetric gap between read and write file-handling logic.
- How it was caught
- Identified through a security review/audit of the codebase that produced a coordinated set of fixes (transport auth, SSRF, authorization, filters, OAuth, and this path-validation gap), not from a reported real-world exploitation.
- What changed
- Patched in mcp-atlassian v0.22.0 via PR #1448 (commit b041733), which adds validate_safe_path(file_path) to upload_attachment and ships a broader security-hardening pass covering HTTP transport authentication, SSRF/DNS-rebinding protection, tool-authorization enforcement, filter allowlists, OAuth token file permissions, and a reflected-XSS fix.
Take-awayWhen adding a path-validation guard to a tool's file-handling code, apply it symmetrically to every entry point that touches the filesystem — an agent-exposed upload path is just as exploitable as a download path if it skips the same check.