| Package | Affected versions | Patched versions |
|---|---|---|
| mcp-atlassian | < 0.22.0 | 0.22.0 |
| mcp atlassian | < 0.22.0 | 0.22.0 |
mcp-atlassian exposes an MCP tool confluence_upload_attachment whose file_path argument is passed directly to open(file_path, "rb") without any path validation. An attacker able to invoke the tool can read arbitrary files readable by the server process and exfiltrate them into a multipart upload directed at an attacker-controlled Confluence host. In the default streamable-http transport the server binds 0.0.0.0 with no built-in authentication, making this remotely exploitable without credentials.
This is the read-side symmetric twin of GHSA-xjgw-4wvw-rgm4 / CVE-2026-27825 (fixed in v0.17.0). The v0.17.0 patch only covered the download/write path; the upload path that reads local files was left unguarded.
src/mcp_atlassian/confluence/attachments.py:477
with open(file_path, "rb") as fp:
files = {"file": (filename, fp, content_type)}
response = self.confluence.session.post(url, files=files, ...)
file_path is attacker-controlled end-to-end.
src/mcp_atlassian/servers/confluence.py:1290-1369, tool definition at :1307:
file_path: Annotated[str, Field(description="Absolute path to the file to upload")]
No Pydantic pattern=, no validator, no validate_safe_path() call.
confluence_upload_attachment(page_id, file_path, ...)ConfluenceFetcher.upload_attachment(file_path)_upload_attachment_direct(file_path) calls open(file_path, "rb")POST /wiki/rest/api/content/{page_id}/child/attachment to the configured Confluence base URL — which the attacker also controls (they provided CONFLUENCE_URL via env/config or target a server they already control).attachments.py:223 (download) — calls validate_safe_path(local_path) before open(..., "wb")attachments.py:272 (download) — calls validate_safe_path(local_path) before open(..., "wb")Running one of these products? Scan your site to see whether it exposes a vulnerable version.
Scan my site freeattachments.py:477 (upload) — no validationThe check_write_access decorator does not help: it only gates READ_ONLY_MODE (default false) and is unrelated to filesystem path safety.
src/mcp_atlassian/__init__.py:151 and :360 — default transport is streamable-http binding HOST=0.0.0.0 with no auth layer. Any network-reachable attacker can call MCP tools directly.
Primary (default streamable-http deployment)
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:N/A:NAlternative (stdio-only deployment, conservative)
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:C/C:H/I:N/A:NMaintainer should pick the vector that reflects the documented default deployment.
CWE-22: Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal')
sooperset/mcp-atlassiand8bc78698a63cb6b321c7ca796d6329d448f7f6d)main.Fully reproduced twice end-to-end against a local stdlib HTTP stub acting as the Confluence API, driven by a real MCP stdio client (mcp.ClientSession + stdio_client) spawning the unmodified mcp-atlassian server at HEAD.
python mock_confluence.py (binds 127.0.0.1:8443, logs all multipart bodies)mcp-atlassian server over stdio with CONFLUENCE_URL=http://127.0.0.1:8443{
"name": "confluence_upload_attachment",
"arguments": {
"page_id": "123456",
"file_path": "/etc/passwd",
"comment": "poc"
}
}
/etc/passwdisError=False, {"message": "Attachment uploaded successfully"}root:x:0:0:root:/root:/bin/bash (and full passwd contents)/etc/hostnameisError=False, same success envelopeang3l-pcBoth runs used unmodified server code at commit d8bc78698a63cb6b321c7ca796d6329d448f7f6d. PoC artifacts (mock_confluence.py, mcp_client.py, poc_run1.sh, poc_run2.sh, asymmetry.txt, ENVIRONMENT.md) available on request to maintainers via this advisory thread.
/etc/passwd, /etc/shadow (if running as root in container), ~/.aws/credentials, ~/.ssh/id_rsa, .env files, kube service-account tokens at /var/run/secrets/kubernetes.io/serviceaccount/token, application source, database dumps, private keys.streamable-http 0.0.0.0 deployment, no credentials are required.GHSA-xjgw-4wvw-rgm4 (CVSS 9.1, fixed in v0.17.0) addressed an arbitrary file write in the same attachments.py module: attacker-controlled paths reaching open(..., "wb") on the download side. The fix introduced validate_safe_path() and applied it at lines 223 and 272.
The upload-side counterpart at line 477 was not updated. Same module, same maintainer, same class of bug (unchecked path → open()), opposite direction (read vs write). This advisory reports the incomplete-fix twin.
Call validate_safe_path(file_path) at the top of ConfluenceFetcher.upload_attachment and _upload_attachment_direct in src/mcp_atlassian/confluence/attachments.py, mirroring the download path at lines 223 and 272. Reject absolute paths outside a configurable allow-listed upload directory and reject any path containing .. after normalization.
Tighten the Pydantic tool schema at src/mcp_atlassian/servers/confluence.py:1307:
file_path: Annotated[
str,
Field(
description="Relative path within the configured upload directory",
pattern=r"^(?!/)(?!.*\.\.)[\w\-./]+$",
),
]
This blocks absolute paths and .. at the MCP schema layer before the handler is even entered.
streamable-http to 127.0.0.1 instead of 0.0.0.0, or require an auth token when bound to a non-loopback interface.file_path must be confined to an operator-chosen directory and expose that directory via config.