GHSA-wm45-qh3g-v83f

Summary

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.)

Details

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...