Threat · curated 15 Sep 2026
NVD-CVE-2026-73496
First reported nist.gov
Coverage timeline
Single-source advisory — first reported, latest, and curated coincide.
Why it matters
CVE-2026-73496 shows how MCP server tools that accept client-controlled file paths can be abused for path traversal and credential/data exfiltration across tenants, a growing risk as agentic MCP deployments move to multi-user remote setups.
CVE-2026-73496 affects MCP Atlassian, a Model Context Protocol server for Confluence and Jira, where the confluence_upload_attachment(s) and jira_update_issue attachment tools pass a client-controlled file_path without confining it to an approved workspace. In remote HTTP, SSE, or multi-user deployments, absolute or traversing paths are resolved on the MCP server, letting a client with write-tool access disclose server files, environment-held Atlassian credentials, or another tenant's data. The issue is fixed in version 0.22.0 (CVSS 3.1 base 7.7).
Summary
CVE-2026-73496 is a path traversal vulnerability (CWE-22 / CWE-73) in MCP Atlassian, a Model Context Protocol server for Atlassian Confluence and Jira products. Prior to version 0.22.0, the confluence_upload_attachment and confluence_upload_attachments tools pass a client-controlled file_path to upload_attachment, and the jira_update_issue attachments parameter reaches the Jira upload_attachment, without confining either path to an approved server workspace.[1]
In remote HTTP, SSE, or multi-user deployments, absolute or traversing paths are resolved on the MCP server and uploaded to Atlassian, allowing a client with write-tool access to disclose server files, environment-held Atlassian credentials, or another tenant's data. A local single-user stdio deployment does not cross this trust boundary because the server runs in the caller's environment. GitHub, Inc. rated the issue CVSS 3.1 7.7 (HIGH), and it is fixed in version 0.22.0.[1]
Disclosure timeline
| Date | Event |
|---|---|
| Sep 14, 2026 | CVE-2026-73496 published to the CVE List and included in the NVD dataset (NVD published and last modified date).[1] |
How it works
The confluence_upload_attachment and confluence_upload_attachments tools pass a client-controlled file_path through src/mcp_atlassian/confluence/attachments.py upload_attachment, and the jira_update_issue attachments parameter reaches src/mcp_atlassian/jira/attachments.py upload_attachment, without confining either path to an approved server workspace.[1]
Because the file path is not restricted, absolute or directory-traversing paths supplied by the client are resolved on the MCP server side and uploaded to Atlassian. In remote HTTP, SSE, or multi-user deployments this crosses a trust boundary, letting a client with write-tool access exfiltrate arbitrary server files, environment-held Atlassian credentials, or another tenant's data. Local single-user stdio deployments are not affected because the server runs in the caller's own environment.[1]
Affected versions and patch status
| Product | Affected | Patch status |
|---|---|---|
| sooperset mcp-atlassian (MCP Atlassian) | All versions prior to 0.22.0 | Fixed in version 0.22.0[1] |
Key takeaways
- Client-controlled file paths in MCP tool parameters must be confined to an approved server workspace; failing to do so enables path traversal that can leak server files, credentials, and other tenants' data in multi-user MCP deployments.[1]
- The severity of this class of flaw depends heavily on deployment model — remote HTTP/SSE/multi-user MCP servers are exposed, while local single-user stdio deployments are not, because they run in the caller's own environment.[1]
Defensive actions
- Upgrade MCP Atlassian to version 0.22.0 or later.: The path traversal issue is fixed in version 0.22.0.[1]
- For deployments that cannot immediately patch, avoid exposing the MCP Atlassian server in remote HTTP, SSE, or multi-user configurations and restrict write-tool access.: The trust boundary is only crossed in remote/multi-user deployments; local single-user stdio deployments do not expose this vulnerability.[1]