MCP Atlassian EUVD-2026-84747

Requires an MCP caller that is already authorized to invoke the attachment tooling (upload_attachment) against a running mcp-atlassian server prior to v0.22.0; the caller then supplies a file_path containing an absolute path or ../ traversal sequence, which the server resolves with only os.path.abspath and never confines to the workspace, then reads and uploads to Jira or Confluence for read-back. Exploitation is limited by needing that attachment-access authorization (PR:L, not unauthenticated) and is most impactful in shared-credential or multi-tenant MCP deployments where the caller should not have host filesystem access; single-trusted-operator deployments face lower practical risk. Impact is confidentiality-only file disclosure - no write, code execution, or availability effect through this specific flaw.

This is a genuine but moderate-severity issue whose real-world risk is bounded by preconditions rather than raw reach. The vendor CVSS 3.1 vector (AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N = 6.5) is internally consistent with the description and source-code evidence: exploitation is remote and low-complexity but requires an authenticated/authorized MCP caller (PR:L) that already has attachment access, and impact is confidentiality-only (C:H, I:N, A:N) - arbitrary server-local file read with no write or availability effect. No EPSS score, no CISA KEV listing, and no public POC were provided, so exploitation status is 'no public exploit identified at time of analysis'; there is no signal of active or automated exploitation. There are no conflicting signals - the CVSS vector matches the described flow (upload_attachment → unconstrained file_path → path traversal), and the fixing commit (b041733473, validate_safe_path) corroborates root cause. The only caveat is that PR:L assumes shared-credential/multi-tenant MCP deployments where a caller is authorized to the tool but should not read the host filesystem; in a single-trusted-operator deployment the practical risk is lower. Overall this is a real vulnerability worth patching in exposed MCP deployments, but not a mass-exploitation priority given the niche product footprint and authorization prerequisite.

An MCP caller authorized to use the Atlassian attachment tool supplies file_path as an absolute path or traversal sequence (e.g. /etc/passwd or ../../secrets.env) to upload_attachment. The server reads that arbitrary local file and uploads it as an attachment to a Jira issue or Confluence page, from which the attacker reads it back - exfiltrating server-local secrets, config, or credential files. No public exploit code is identified, but the traversal is trivial to trigger once attachment access is granted.