GHSA-93xw-j965-9mx3: Path Traversal

Published Sep 22, 2026
·
Updated

Summary

The uploadattachment method in confluence/attachments.py reads and uploads arbitrary local files to Confluence without calling validatesafepath(). Both download methods (downloadattachment at line 223, downloadcontentattachments at line 272) correctly call validatesafepath() before writing files, but the upload path at lines 35-79 skips this check entirely.

An AI agent connected via MCP (or an attacker influencing that agent through prompt injection) can read any file on the host and exfiltrate it by uploading it as a Confluence page attachment.

Vulnerable Code

File: src/mcpatlassian/confluence/attachments.py, lines 62-79

python No validatesafepath() call anywhere in this method if not os.path.isabs(filepath): filepath = os.path.abspath(filepath)

if not os.path.exists(filepath): return {"success": False, "error": f"File not found: {filepath}"}

filename = os.path.basename(filepath) attachment = self.uploadattachmentdirect( contentid, filepath, filename, comment, minoredit )

The validatesafepath function is already imported at line 9 of the same file, and used in the download methods. It was just not added to the upload path.

Proof of Concept

Tested with mcp-atlassian 0.21.1 on Python 3.11 (EC2, Amazon Linux 2023).

python import inspect from mcpatlassian.confluence.attachments import AttachmentsMixin

Confirm: no validatesafepath in upload source = inspect.getsource(AttachmentsMixin.uploadattachment) assert "validatesafepath" not in source # passes

Confirm: validatesafepath IS in downloads assert "validatesafepath" in inspect.getsource(AttachmentsMixin.downloadattachment) # passes assert "validatesafepath" in inspect.getsource(AttachmentsMixin.downloadcontentattachments) # passes

An MCP tool call like this reads /etc/passwd and uploads it to Confluence:

json {"tool": "confluenceuploadattachment", "arguments": {"contentid": "123456", "filepath": "/etc/passwd"}}

Impact

Exfiltration of any file readable by the MCP server process: SSH keys, AWS credentials, .env files, /etc/passwd, application secrets. Data leaves the local machine and lands on a remote Confluence instance accessible to other users.

Suggested Fix

Add validatesafepath(filepath) before the os.path.exists() check in uploadattachment, matching the existing pattern in the download methods. The function is already imported.

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

    In `src/mcp_atlassian/confluence/attachments.py`, add `validate_safe_path(file_path)` before the `os.path.exists()` check in `upload_attachment`, matching the validation already used by the download methods.

Event History

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

Frequently Asked Questions

1

Who can realistically trigger the exposure?

An AI agent connected through MCP can trigger it. An attacker who can influence that agent through prompt injection can cause the agent to read a local file and upload it as a Confluence attachment.

2

Are the attachment download functions affected too?

The described issue is limited to the upload path. The two download methods named in the advisory call validate_safe_path() before writing files, while upload_attachment() does not validate the supplied local path.

3

What local paths can the upload method use?

It accepts absolute paths and converts relative paths to absolute paths. If the resulting path exists, it uses that file for the attachment upload without a validate_safe_path() check.

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