CVE-2026-73496: 
Python vulnerability analysis and mitigation

CVE-2026-73496 is a path traversal vulnerability (CWE-22/CWE-73) in mcp-atlassian, a Model Context Protocol (MCP) server for Atlassian Confluence and Jira. In remote HTTP, SSE, or multi-user deployments, the confluence_upload_attachment, confluence_upload_attachments, and jira_update_issue (attachments parameter) tools accept a client-controlled file_path that is resolved and read directly on the MCP server without confinement to an approved workspace directory, enabling arbitrary server-side file exfiltration. All versions prior to 0.22.0 are affected; local single-user stdio deployments are not impacted because the server runs in the caller's own environment. The vulnerability carries a CVSS v3.1 base score of 7.7 (High) (GitHub Advisory, Feedly).

The root cause is improper limitation of a pathname to a restricted directory (CWE-22) combined with external control of file name or path (CWE-73). In src/mcp_atlassian/confluence/attachments.py, the upload_attachment function called os.path.abspath(file_path) — which only normalizes the path without restricting it — then passed the result directly to open(file_path, "rb") and uploaded the file bytes to Atlassian. The same pattern existed in src/mcp_atlassian/jira/attachments.py. Because the path is resolved on the server rather than the client, a remote MCP client can supply absolute paths (e.g., /etc/passwd, /proc/self/environ) or relative traversal sequences (e.g., ../../../../etc/hostname) to read any file accessible to the server process. Three client-reachable entry points hit these sinks: confluence_upload_attachment, confluence_upload_attachments, and jira_update_issue (via its attachments parameter). A proof-of-concept was included in the advisory demonstrating a full round-trip exfiltration of /etc/passwd and /proc/self/environ via the Confluence and Jira upload tools (GitHub Advisory, Fix PR).

Any authenticated MCP client with write-tool access can exfiltrate arbitrary files readable by the server process — including /etc/passwd, application configuration files, TLS key material, and /proc/self/environ. Reading /proc/self/environ discloses the server's environment variables, which typically include JIRA_API_TOKEN and CONFLUENCE_API_TOKEN, effectively handing the attacker the operator's full Atlassian credentials. In multi-tenant HTTP deployments, this also breaks tenant isolation, allowing one client to read files belonging to other tenants or the deployment infrastructure itself. There is no integrity or availability impact; the vulnerability is purely a high-severity confidentiality breach (GitHub Advisory).

A working proof-of-concept is publicly documented in the GitHub Security Advisory, demonstrating exploitation via curl and jq against a Docker-based mcp-atlassian instance with READ_ONLY_MODE=false (the default). Exploitation requires only low privileges — a client with write-tool access — and no user interaction. The EPSS score is 0.0 at time of publication, and there is no evidence of in-the-wild exploitation or CISA KEV catalog listing as of the advisory date. No threat actor attribution has been reported (GitHub Advisory, Feedly).

1. Identify a vulnerable target: Locate a remotely accessible mcp-atlassian instance (HTTP/SSE transport, READ_ONLY_MODE=false) running a version prior to 0.22.0, typically listening on 0.0.0.0 by default.
2. Authenticate as a low-privilege MCP client: Obtain or use any valid MCP client credential that grants access to write tools (e.g., confluence_upload_attachment or jira_update_issue).
3. Exfiltrate /etc/passwd via Confluence upload: Send an MCP tools/call request targeting confluence_upload_attachment with file_path set to /etc/passwd and a valid content_id. The server reads and uploads the file to Atlassian as an attachment.

   {"tool": "confluence_upload_attachment", "arguments": {"content_id": "<PAGE_ID>", "file_path": "/etc/passwd"}}

4. Retrieve the exfiltrated content: Call confluence_download_attachment with the returned attachment_id to receive the file contents base64-encoded in the MCP response, confirming the server-side read.
5. Exfiltrate credentials via /proc/self/environ: Repeat step 3 with file_path set to /proc/self/environ to obtain the server's environment variables, including JIRA_API_TOKEN and CONFLUENCE_API_TOKEN.
6. Use relative traversal as an alternative: Supply a traversal path such as ../../../../etc/hostname if absolute paths are monitored, as the server resolves relative paths without containment.
7. Exploit via Jira entry point: Alternatively, call jira_update_issue with the attachments parameter set to the target file path to reach the Jira-side sink.

   {"tool": "jira_update_issue", "arguments": {"issue_key": "<KEY>", "fields": "{}", "attachments": "/etc/passwd"}}

   (GitHub Advisory)

• Network: Outbound HTTPS requests from the mcp-atlassian server to Atlassian Cloud APIs (api.atlassian.com, *.atlassian.net) uploading files with names matching sensitive system paths (e.g., passwd, environ, hostname, shadow).
• Logs: MCP server access logs showing tools/call requests to confluence_upload_attachment, confluence_upload_attachments, or jira_update_issue with file_path or attachments values containing absolute paths (e.g., /etc/, /proc/) or traversal sequences (../).
• Atlassian UI: Unexpected attachments appearing on Confluence pages or Jira issues with filenames such as passwd, environ, hostname, shadow, or other system file names not associated with normal business content.
• File System: No direct file system artifacts on the server; the attack reads existing files without writing new ones.
• Process: The mcp-atlassian Python process opening file descriptors to paths outside its working directory (observable via lsof or auditd rules on sensitive paths like /etc/passwd, /proc/self/environ) (GitHub Advisory).

Upgrade mcp-atlassian to version 0.22.0 or later, which introduces validate_safe_path to confine all caller-supplied file paths to the server's working directory before any file is opened. After upgrading, file paths passed to upload tools must resolve inside the server's working directory — absolute or traversal paths are rejected. No configuration-based workaround is available for versions prior to 0.22.0; as an interim measure, operators can restrict MCP client access to trusted users only and set READ_ONLY_MODE=true (which disables write tools including the vulnerable upload tools). Operators should also rotate any JIRA_API_TOKEN and CONFLUENCE_API_TOKEN values if the server was exposed to untrusted clients while running a vulnerable version (GitHub Advisory, v0.22.0 Release).

The vulnerability was discovered by Francisco Rosales of Manifold Security (credited as 0xmagic0) and disclosed through GitHub's coordinated security advisory process alongside 36 other advisories resolved in the v0.22.0 security hardening pass. The maintainer (sooperset) published the advisory and fix simultaneously on July 10, 2026, with a comprehensive PR (#1448) that addressed the full family of path traversal and related security issues. The release notes acknowledge additional public reports from @failsafesecurity and @rober15 for overlapping issues (GitHub Advisory, v0.22.0 Release).