MCP Atlassian CVE-2026-77253

Requires (1) the MCP server deployed in HTTP or multi-user mode - not the single-user stdio mode - so the client-to-server filesystem boundary actually exists and is meaningful; (2) a permitted/authenticated MCP caller able to invoke the jira_upload_attachment or confluence_upload_attachment tools (PR:L); and (3) shared operator credentials so the caller's uploads land in an Atlassian space the caller can read back. The specific attacker-controlled input is the file_path argument, which pre-fix was only run through os.path.abspath() rather than confined to the workspace, letting absolute or traversal paths escape CWD. Limiting factors: exploitation is confined to files readable by the MCP process, yields disclosure (and incidental write of stolen bytes into Atlassian) but no code execution or availability impact, and single-user local stdio deployments are not meaningfully exposed.

This is a genuine-but-conditional risk, not a top-tier emergency. The vendor CVSS 3.1 vector (AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:L/A:N, 7.1 HIGH) is internally consistent with the description: network-reachable, low-complexity, but requiring a permitted (authenticated) caller - PR:L is correct because the attacker must already be an authorized MCP client, and exploitation only crosses a security boundary in HTTP or multi-user deployments. No EPSS score, no CISA KEV listing, and no public POC are present in the input, so all three exploitation-likelihood signals are absent - status is 'no public exploit identified at time of analysis.' The impact is primarily confidentiality (C:H) with only incidental integrity (I:L, from writing the exfiltrated bytes into an Atlassian attachment) and no availability impact, which matches a file-disclosure primitive rather than RCE. Real-world priority is dampened by two structural gates: the affected product is a niche open-source MCP server, and the dangerous path only opens when the server runs in a shared-credential HTTP/multi-user mode rather than the common single-user stdio mode. There is no conflict between the CVSS vector and the description; the main caveat is that severity hinges entirely on deployment topology, which raw CVSS cannot capture.

An MCP server for Confluence/Jira is deployed in HTTP or multi-user mode with shared operator credentials. A permitted-but-untrusted caller invokes jira_upload_attachment or confluence_upload_attachment with file_path set to a server-local path such as an OAuth token file, .env, or a mounted Kubernetes secret; the server reads those bytes and uploads them to Atlassian, where the caller reads them back. No public exploit code is identified, but the code path is documented in the fixing PR #1448 diff.