CVE-2026-77248: MCP Atlassian: Unauthenticated arbitrary local file read via upload_attachment file_path, chained with missing auth on streamable-http transport
Summary In the documented multi-user HTTP deployment (--transport streamable-http with global operator Atlassian credentials), sooperset/mcp-atlassian exposes all tools to unauthenticated network clients, and the uploadattachment tool reads an attacker-supplied filepath with no path validation. Chained, an unauthenticated network attacker reads arbitrary files on the MCP server host (e.g. /proc/self/environ → the operator's Atlassian API token + .env secrets, ~/.ssh/idrsa, /etc/passwd) by uploading them to an attacker-chosen page/issue and reading them back.
Details Missing authentication (transport): - streamable-http binds 0.0.0.0 by default (src/mcpatlassian/init.py:151). - The OAuth-proxy auth provider is opt-in (ATLASSIANOAUTHPROXYENABLE, default false), so mainmcp is built with auth=None (src/mcpatlassian/servers/main.py:724-731, 813-817). - UserTokenMiddleware.parseauthheader sets authvalidationerror only for a malformed Authorization header; a request with no Authorization header passes through (main.py:416-446, 582-595). - getfetcher then falls through to the global credential fallback using the operator's .env Atlassian token (src/mcpatlassian/servers/dependencies.py:644-676). checkwriteaccess gates only on read-only mode, not auth → read and write tools reachable.
Arbitrary file read (sink): - uploadattachment's filepath flows unsanitized into open(filepath, 'rb') — Confluence src/mcpatlassian/confluence/attachments.py:477 (from servers/confluence.py:1294-1369); Jira src/mcpatlassian/jira/attachments.py:386 (from servers/jira.py:1609-1673). No validatesafepath / allowlist (contrast the download flow, hardened after CVE-2026-27825).
Proof of Concept unauthenticated (no Authorization header) against a default streamable-http deployment: tools/call uploadattachment { "filepath": "/proc/self/environ", "pageid": "<attacker-chosen>" } then read it back: tools/call downloadattachment { ... } # returns the bytes (base64) -> operator's ATLASSIAN token + .env secrets
Impact Unauthenticated arbitrary local file read on the MCP server host — including the operator's Atlassian API token and .env secrets — a boundary the Atlassian-scoped tool must not cross, plus unauthenticated use of every read/write Atlassian tool as the operator's (often admin) principal. Distinct from GHSA-xjgw-4wvw-rgm4 (file write via downloadpath) and GHSA-7r34-79r5-rcc9 (URL-header SSRF).
Suggested fix Require authentication on the streamable-http transport by default (do not fall back to operator global credentials for unauthenticated requests); apply validatesafepath/allowlist to filepath in uploadattachment as the download flow already does.
Affected mcp-atlassian <= 0.21.1.
Other sources
MCP Atlassian is a Model Context Protocol (MCP) server for Atlassian products (Confluence and Jira). Prior to 0.22.0, the streamable HTTP transport accepts requests without a user identity and falls back to operator credentials, while uploadattachment accepts an unrestricted filepath. An unauthenticated network caller can read files available to the MCP process, upload them to an attacker-selected Jira issue or Confluence page, and retrieve the contents. The advisory traces the vulnerable input and processing flow through streamable-http, UserTokenMiddleware, uploadattachment, filepath, and getfetcher, which identify the affected entry points, controls, and code paths. This issue is fixed in version 0.22.0.
— MITRE
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
pip/mcp-atlassianto a version that resolves this vulnerability.Fixed in 0.22.0 - Upgrade
Upgrade
mcp-atlassianto a version that resolves this vulnerability.Fixed in 0.22.0
Event History
Frequently Asked Questions
Who is exposed to exploitation?
Deployments running MCP Atlassian before 0.22.0 that expose the streamable HTTP transport to network callers are exposed. The attacker does not need an authenticated user identity because the affected transport falls back to operator credentials.
What does an attacker need to exploit this issue?
An attacker needs network access to the affected streamable HTTP transport. They can supply a file_path to upload_attachment and select a Jira issue or Confluence page to receive the uploaded file.
What data can be accessed?
The attacker can read files that are available to the MCP process. The file contents can be uploaded as an attachment and then retrieved from the selected Jira issue or Confluence page.
What should be done to remediate the issue?
Upgrade MCP Atlassian to version 0.22.0, which fixes the issue. The vulnerable behavior affects versions prior to 0.22.0.