GHSA-6cr4-ccf3-x7h4: Path Traversal

Published Sep 22, 2026
·
Updated

Summary

Missing path validation in confluenceuploadattachment 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.uploadattachment() in src/mcpatlassian/confluence/attachments.py opens the caller-supplied filepath with no boundary check:

python line 477 files = {"file": (filename, open(filepath, "rb"))} The download path was correctly hardened in GHSA-xjgw-4wvw-rgm4 via validatesafepath() (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 filepath 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 confluenceuploadattachment( contentid = "<any page attacker can edit>", filepath = "/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/mcpatlassian/confluence/attachments.py — uploadattachment() Add after abspath conversion, before open():

try: validatesafepath(filepath) except ValueError as e: return {"success": False, "error": str(e)}

Same fix required in uploadattachments() and src/mcpatlassian/jira/attachments.py.

Affected Software

1 affected componentFixes available
pip/mcp-atlassian<0.22.0
0.22.0

Remediation

Recommended actions to resolve this vulnerability, in priority order.

  1. Upgrade

    Upgrade pip/mcp-atlassian to a version that resolves this vulnerability.

    Fixed in 0.22.0
  2. Compensating control

    Add validate_safe_path(file_path) after abspath conversion and before open() in AttachmentsMixin.upload_attachment(); apply the same path validation to upload_attachments() and src/mcp_atlassian/jira/attachments.py.

Event History

Sep 22, 2026
Advisory Published
via GitHub·08:35 PM
Data Sourced
via GitHub·08:35 PM
DescriptionSeverityWeaknessAffected Software

Frequently Asked Questions

1

What access does an attacker need to exploit this?

The attacker needs an authenticated MCP client and a Confluence page that they can edit, so they can invoke the attachment upload tool with a chosen file path and upload the result to that page.

2

What files are at risk of disclosure?

Any file readable by the server process can be opened through the caller-supplied file path and uploaded to Confluence. On Linux, /proc/self/environ can expose all runtime secrets in a single request.

3

What evidence could indicate successful exploitation?

A successful attempt creates a Confluence attachment on a page the attacker can edit, with the attachment containing the raw contents of the selected server-side file.

Contact

SecAlerts Pty Ltd.
132 Wickham Terrace
Fortitude Valley,
QLD 4006, Australia
info@secalerts.co
By using SecAlerts services, you agree to our services end-user license agreement. This website is safeguarded by reCAPTCHA and governed by the Google Privacy Policy and Terms of Service. All names, logos, and brands of products are owned by their respective owners, and any usage of these names, logos, and brands for identification purposes only does not imply endorsement. If you possess any content that requires removal, please get in touch with us.
© 2026 SecAlerts Pty Ltd.
ABN: 70 645 966 203, ACN: 645 966 203