GHSA-cc5h-2pwp-pvcc: Path Traversal
Summary In the documented multi-user HTTP deployment (--transport streamable-http with global operator Atlassian credentials), sooperset/mcp-atlassian exposes all tools to unauthenticated network clients, and the uploadattachment tool reads an attacker-supplied filepath with no path validation. Chained, an unauthenticated network attacker reads arbitrary files on the MCP server host (e.g. /proc/self/environ → the operator's Atlassian API token + .env secrets, ~/.ssh/idrsa, /etc/passwd) by uploading them to an attacker-chosen page/issue and reading them back.
Details Missing authentication (transport): - streamable-http binds 0.0.0.0 by default (src/mcpatlassian/init.py:151). - The OAuth-proxy auth provider is opt-in (ATLASSIANOAUTHPROXYENABLE, default false), so mainmcp is built with auth=None (src/mcpatlassian/servers/main.py:724-731, 813-817). - UserTokenMiddleware.parseauthheader sets authvalidationerror only for a malformed Authorization header; a request with no Authorization header passes through (main.py:416-446, 582-595). - getfetcher then falls through to the global credential fallback using the operator's .env Atlassian token (src/mcpatlassian/servers/dependencies.py:644-676). checkwriteaccess gates only on read-only mode, not auth → read and write tools reachable.
Arbitrary file read (sink): - uploadattachment's filepath flows unsanitized into open(filepath, 'rb') — Confluence src/mcpatlassian/confluence/attachments.py:477 (from servers/confluence.py:1294-1369); Jira src/mcpatlassian/jira/attachments.py:386 (from servers/jira.py:1609-1673). No validatesafepath / allowlist (contrast the download flow, hardened after CVE-2026-27825).
Proof of Concept unauthenticated (no Authorization header) against a default streamable-http deployment: tools/call uploadattachment { "filepath": "/proc/self/environ", "pageid": "<attacker-chosen>" } then read it back: tools/call downloadattachment { ... } # returns the bytes (base64) -> operator's ATLASSIAN token + .env secrets
Impact Unauthenticated arbitrary local file read on the MCP server host — including the operator's Atlassian API token and .env secrets — a boundary the Atlassian-scoped tool must not cross, plus unauthenticated use of every read/write Atlassian tool as the operator's (often admin) principal. Distinct from GHSA-xjgw-4wvw-rgm4 (file write via downloadpath) and GHSA-7r34-79r5-rcc9 (URL-header SSRF).
Suggested fix Require authentication on the streamable-http transport by default (do not fall back to operator global credentials for unauthenticated requests); apply validatesafepath/allowlist to filepath in uploadattachment as the download flow already does.
Affected mcp-atlassian <= 0.21.1.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
pip/mcp-atlassianto a version that resolves this vulnerability.Fixed in 0.22.0 - Configuration
Enable the OAuth-proxy authentication provider and require authentication by default; unauthenticated requests must not fall back to the operator's global Atlassian credentials.
mcp-atlassian streamable-http transport ATLASSIAN_OAUTH_PROXY_ENABLE = true - Compensating control
Apply validate_safe_path or an equivalent allowlist to the upload_attachment file_path parameter, as already done for the download flow, so it cannot read arbitrary files from the MCP server host.
Event History
Frequently Asked Questions
Which deployments are exposed to unauthenticated access?
The described exposure applies to the documented multi-user deployment using --transport streamable-http with global operator Atlassian credentials. This transport binds to 0.0.0.0 by default, making it reachable by network clients unless network controls restrict access.
Does the default authentication configuration prevent exploitation?
No. The OAuth-proxy authentication provider is opt-in and disabled by default, and requests with no Authorization header pass through without an authentication validation error. The server can then fall back to the configured global credentials.
What does an attacker need to exploit the file-read behavior?
An attacker needs network access to the streamable HTTP service; no authentication is required in the described configuration. They can supply a file path to upload_attachment and use an attacker-chosen Atlassian page or issue to retrieve the uploaded file contents.