Executive brief
The MCP Atlassian server, when deployed in HTTP transport mode, accepts arbitrary file paths in attachment upload tools without validation. An unauthenticated attacker can supply forged Atlassian service headers to redirect uploads to an attacker-controlled endpoint and exfiltrate sensitive files (credentials, SSH keys, environment files) readable by the server process. No authentication or authorization headers are required.
Technical details
The vulnerability is a server-side file exfiltration (CWE-200) in the `confluence_upload_attachment` and `jira_upload_attachment` MCP tools. The attack chain combines three weaknesses: (1) HTTP header-based "authentication" that bypasses authorization when no Authorization header is present and attacker-supplied `X-Atlassian-Confluence-Url` / `X-Atlassian-Confluence-Personal-Token` headers are provided; (2) insufficient SSRF validation that permits attacker-controlled domains; and (3) absence of path sanitization in the attachment upload code path (while the download path correctly calls `validate_safe_path()`). The file_path argument is converted to an absolute path via `os.path.abspath()` but never restricted to a safe directory, allowing reads of `/etc/passwd`, `~/.env`, SSH keys, and cloud credentials. The vulnerability requires HTTP transport mode and `READ_ONLY_MODE=false` (both defaults in documented deployments), but no prior authentication.
Affected products
- Atlassian MCP Atlassian Prior to patch (commit d8bc786)
Timeline
- 2026-09-22: disclosed: GHSA-wv8v-v4c5-v75j published
- 2026: other: CVE-2026-77246 assigned