MCP Atlassian EUVD-2026-84605

Requires an MCP caller that is authorized to invoke the Jira (jira_upload_attachment) or Confluence (confluence_upload_attachment) attachment-upload tools against the MCP Atlassian server prior to 0.22.0 (PR:L, network-reachable). No user interaction and no special non-default configuration is needed - the vulnerable code trusts any caller-supplied file_path and, before the fix, only converted relative paths to absolute (os.path.abspath) without confining them to a workspace. Impact is limited to files readable by the server process account, and exploitation is gated by having upload authorization; the danger is greatest in shared-credential or multi-tenant deployments where a low-privilege caller can thereby read host secrets (tokens, keys, config) beyond its intended Atlassian scope.

This is a genuine but moderate-priority issue, well-calibrated at CVSS 6.5. The vendor vector CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N is consistent with the description: an authenticated MCP caller (PR:L) with attachment-upload access can read arbitrary server-local files, yielding a confidentiality-only impact (C:H, I:N, A:N). No EPSS score, no CISA KEV listing, and no public exploit were provided, so this is no public exploit identified at time of analysis - not active exploitation. The realistic risk is bounded by the required upload authorization and by the still-emerging deployment footprint of this niche OSS project; it is not an internet-wide unauthenticated RCE. The one metric worth scrutiny is Scope: because the flaw lets a caller read files entirely outside the intended Atlassian data domain (any file the server process can read, e.g. /etc, credentials, keys), an S:C argument is defensible, which would raise the score; the sibling Confluence-only advisory CVE-2026-77258 was in fact scored S:C. I retain S:U to match the vendor but flag the ambiguity. Priority elevates in shared-credential/multi-tenant deployments where a low-privilege caller can exfiltrate host secrets.

An MCP client authorized to use the Jira or Confluence attachment-upload tools supplies file_path=/etc/passwd (or a path to a service-account token, SSH key, or .env file) instead of a legitimate attachment. The server opens that file and uploads it to an attacker-controlled issue or page, after which the attacker downloads the attachment to read the contents. No public exploit code was identified, but the flaw is trivially reproducible given the described open(file_path, 'rb') sink and the low attack complexity (AC:L).