[*] Target file : /etc/passwd
[*] Calling : ConfluenceAttachmentsMixin.upload_attachment()
[*] Return value: {'success': True, 'content_id': '123456', 'filename': 'passwd', 'size': 3388, 'id': 'att-99'}
[*] Files opened: ['/etc/passwd']
[!!!] VULNERABLE — /etc/passwd opened without validate_safe_path()
upload_attachment() → _upload_attachment_direct() → open(file_path)
download_attachment() in same file IS protected — asymmetric fix
Key evidence:
success: True — no exception raised, no path validation triggered
size: 3388 — /etc/passwd was opened and read by os.path.getsize()
Both modules affected independently — neither Jira nor Confluence has an upload-side guard
In a live deployment, the file content is streamed directly to the Atlassian API and stored as a visible attachment on the issue or page.
Impact
Any authenticated MCP client — including a compromised AI agent, a prompt-injected session, or a malicious plugin — can read and exfiltrate arbitrary files readable by the server process:
/etc/shadow — system password hashes
/proc/self/environ — process environment variables (API keys, secrets)
No special privileges beyond standard MCP tool access are required. The vulnerability affects both HTTP-mode (multi-user) and stdio-mode (local) deployments. Both the jira_upload_attachment and confluence_upload_attachment MCP tools are affected.
Root cause: The validate_safe_path() utility introduced in GHSA-xjgw-4wvw-rgm4 was applied only to download operations. The upload path in both modules was never patched, leaving a symmetric file-read vector open.