Attack ChainAIDerived
Hypothetical attack flow derived from CVE metadata – not a confirmed exploit chain
-
AccessAuthenticate to remote HTTP/SSE MCP server
-
DeliveryCall confluence_upload_attachment with absolute host path
-
Exploitvalidate_safe_path passes under filesystem-root CWD
-
ExecutionServer reads arbitrary host file
-
ImpactExfiltrate file contents to attacker-controlled Confluence
Vulnerability Assessment
| Weakness |
CWE
OWASP Top 10:2025
A01:2025 - Broken Access Control
ASVS 5.0
V5 - File Handling Path canonicalization, traversal prevention
MITRE ATT&CK
2 techniques across 2 tactics: Discovery, Collection The technique list with ATT&CK links and the kill-chain view is part of the Basic plan and up. |
| Exploitation Conditions | Requires a remote multi-user transport (streamable-http or SSE, e.g. 'uvx mcp-atlassian --transport streamable-http') AND the server process must have been started from a wide working directory: a systemd system unit without WorkingDirectory= (cwd '/'), a systemd user unit (cwd $HOME), or a shell/uvx launch inheriting a broad cwd. The attacker must be an authenticated remote MCP caller able to invoke confluence_upload_attachment (consistent with PR:L). Limiting factors that reduce real-world exposure: the official Docker image is NOT affected (pinned WORKDIR /app keeps the guard effective), local stdio desktop usage is intended behavior and not a vulnerability, and containerized orchestration from the official image is protected. The unauthenticated position is only restored if the operator additionally sets ALLOW_GLOBAL_CRED_FALLBACK=true on a wide-cwd host. |
| Impact | Signals point to a low-to-moderate real-world priority with one notable internal conflict. The vendor-assigned CVSS 4.0 base score is 2.1 (low) with PR:L (authenticated) and only VC:L confidentiality impact, and the vuln.today decision label is 'monitor' - consistent with a non-urgent issue. However, the GHSA advisory (GHSA-qh7q-jmc7-rc7j) describes the concrete impact as arbitrary file read of sensitive host files (/etc/passwd, /proc/self/environ containing Atlassian API tokens, .env files, SSH keys) exfiltrated to the attacker's Confluence - which is materially higher than the VC:L the CVSS vector claims; treat the assigned confidentiality metric as likely understated versus the advisory's own impact narrative. Exploitation is gated: it only works on remote HTTP/SSE multi-user deployments where the server process starts from a wide working directory, so the low CVSS partly reflects that deployment dependency rather than a benign bug. No KEV listing and no EPSS score are present in the input, and exploitation is not confirmed in the wild. The PoC is a reference in the advisory, not verified working exploit code. Net: patch within a normal maintenance cycle; it is not an emergency, but operators running non-containerized remote deployments should prioritize it above its raw 2.1 score because the real impact is arbitrary file read of secrets. |
| Exploit ScenarioDerived | On a remote streamable-http/SSE deployment of mcp-atlassian started from a wide working directory (e.g., a systemd system unit with cwd '/'), an authenticated MCP caller invokes the confluence_upload_attachment tool with file_path set to an absolute host path such as /proc/self/environ or an .env file. Because validate_safe_path confines the source only to the process CWD, every absolute path passes when the CWD is the filesystem root, so the server reads the file and uploads its contents to the caller's own Confluence instance. A public PoC reference exists in the GHSA advisory (end-to-end reproduction described), but it is not verified as working exploit code in the input. |
Get an e-mail when this CVE is exploited, patched or re-scored. Free account.
Alert meAnalysisAIv1 – Nov 10, 2026
Arbitrary file read and exfiltration in sooperset mcp-atlassian before 0.24.1: an authenticated remote MCP caller can point the confluence_upload_attachment tool at any file the server process can read, and the server uploads that file's contents into the caller's own Confluence instance. The guard added in the earlier hardening batch (validate_safe_path in src/mcp_atlassian/utils/io.py) confines attachment source paths to os.getcwd(), so a streamable-http or SSE deployment whose process was started from a wide working directory - a systemd system unit defaulting to '/', a systemd user unit or shell/uvx launch defaulting to $HOME - makes the boundary vacuous, while the official Docker image (pinned WORKDIR /app) and local stdio desktop use are not affected. Vendor-released patch: 0.24.1; there is no CISA KEV entry, a public PoC reference exists but is not verified as working exploit code, and the priority signal is monitor.
RemediationAI
Upgrade mcp-atlassian to 0.24.1 (https://github.com/sooperset/mcp-atlassian/releases/tag/v0.24.1, advisory https://github.com/sooperset/mcp-atlassian/security/advisories/GHSA-qh7q-jmc7-rc7j, fix in PR https://github.com/sooperset/mcp-atlassian/pull/1448) - this is the only complete fix and the release is the version the advisory records as patched. If upgrading cannot happen immediately, the actionable compensating control is to narrow the guard boundary operationally, since the guard is only as strong as the process cwd: set an explicit WorkingDirectory= in systemd units (the default is '/' for system units and $HOME for user units) or launch the uvx/streamable-http server from a dedicated, empty workspace directory, which makes validate_safe_path confine uploads to that directory - the trade-off is that legitimate attachment uploads from other paths will then fail with a path-traversal error and must be staged inside the chosen directory. Running the official Docker image or container orchestration derived from it keeps cwd pinned to /app and preserves the guard. Also leave ALLOW_GLOBAL_CRED_FALLBACK at its default (unset) so the unauthenticated global-credential fallback path stays closed on wide-cwd hosts; enabling it restores an unauthenticated attacker position. Local stdio desktop use needs no change, as the project treats local file reads there as intended behavior.
Affected VersionsENISA
Affected Packages
Source: OSV (Open Source Vulnerabilities)
Affects your stack
Affects 1 package in euvd
Checking this CVE against your own stacks and servers is part of the Basic plan and up.
Technical ContextAI · show details
The root cause is CWE-22 (path traversal) in the upload-side guard rather than in the resolve logic itself. validate_safe_path() in src/mcp_atlassian/utils/io.py defaults base_dir to os.getcwd() and rejects paths that fail resolved_path.is_relative_to(resolved_base); the check correctly resolves symlinks and refuses '../' and symlink escapes, but the boundary it enforces is whatever working directory the process happens to inherit. The package never calls chdir, exposes no configuration key for the guard base directory, and emits no warning when a remote transport starts from a wide cwd. On the upload chain (src/mcp_atlassian/confluence/attachments.py calling validate_safe_path without a base_dir before open(file_path, "rb") and _upload_attachment_direct, reached through the tool in src/mcp_atlassian/servers/confluence.py), an absolute path is accepted whenever cwd is the filesystem root or a home directory, so /etc/passwd, /proc/self/environ (holding the operator's JIRA_API_TOKEN / CONFLUENCE_API_TOKEN), .env files and SSH keys can be read and pushed out through the tool's designed attachment output - indistinguishable in server logs from a legitimate upload. The trigger requires a remote multi-user transport (streamable-http or SSE as documented in docs/http-transport.mdx) plus a wide startup cwd; the vulnerable position is the authenticated remote MCP caller used by the accepted upload advisories, and the unauthenticated position only reappears if an operator explicitly sets ALLOW_GLOBAL_CRED_FALLBACK=true on a wide-cwd host. The same boundary mistake was previously accepted on the download side (CVE-2026-77271 / GHSA-6vmq-24h2-pj7j), where the recommendation was to pass an explicitly configured base directory instead of relying on cwd; GitHub Security Advisory GHSA-qh7q-jmc7-rc7j closes this read-side case, with duplicate reports GHSA-2wxc-q7pq-4hfx and GHSA-36pc-mf7c-2p36 folded into it, and the accompanying PR #1448 also adds SSRF redirect validation/DNS pinning and an always-applied CQL spaces allowlist.
Know when Mcp Atlassian gets its next vulnerability
- Watch products and get an email when something new is published
- Check this CVE against your own stack and servers
- Exploit and PoC references, threat intelligence from 22 sources
No credit card · 7-day full trial
Severity by source
CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:L/VI:N/VA:N/SC:N/SI:N/SA:N/E:P
Authenticated remote MCP caller (PR:L) trivially triggers arbitrary file read of host secrets once the server runs from a wide CWD, giving C:H; no integrity or availability impact, with the wide-CWD deployment treated as a population limiter rather than attacker complexity.
Primary rating from Vendor (VulDB).
CVSS VectorVendor: VulDB
Lifecycle Timeline
3DescriptionCVE.org
A vulnerability was identified in sooperset mcp-atlassian up to 0.24.0. This issue affects the function validate_safe_path of the file src/mcp_atlassian/utils/io.py. The manipulation of the argument path leads to path traversal. The attack may be initiated remotely. The exploit is publicly available and might be used. Upgrading to version 0.24.1 is capable of addressing this issue. Upgrading the affected component is recommended. This CVE was requested by the vendor.
Threat Intelligence Overview
How this decision was reached
The engine reads each signal below and applies a fixed list of rules from top to bottom. The first rule that matches sets the recommended action – like a statement, every line is shown.
What every action level means
SSVC AssessmentENISA
Priority Score
Attack Technique
Path traversal exploits occur when applications use user-controlled input to construct file system paths without proper validation.
More in Mcp Atlassian
View allServer-side request forgery in MCP Atlassian (the Model Context Protocol server for Confluence and Jira) prior to 0.22.0
MCP Atlassian (sooperset/mcp-atlassian) before 0.22.0 applies its ENABLED_TOOLS and TOOLSETS least-privilege filters onl
Path traversal in MCP Atlassian releases prior to 0.22.0 lets a caller of the confluence_upload_attachment MCP tool read
Unauthenticated arbitrary file read in MCP Atlassian (sooperset/mcp-atlassian) before 0.22.0 lets a remote network calle
Arbitrary local file read leading to data exfiltration affects sooperset's MCP Atlassian server (mcp-atlassian) prior to
Unauthenticated server-local file exfiltration in MCP Atlassian (sooperset/mcp-atlassian) before 0.22.0 allows a remote
Server-side request forgery in MCP Atlassian prior to 0.22.0 lets an attacker who controls or has already compromised th
MCP Atlassian (sooperset/mcp-atlassian) before 0.22.0 lets a low-privileged authenticated MCP caller write attacker-chos
Server-side request forgery in MCP Atlassian (sooperset/mcp-atlassian) before 0.22.0 allows a low-privileged authenticat
Arbitrary local file read in MCP Atlassian (mcp-atlassian) prior to 0.22.0 allows an authenticated MCP caller who can re
Arbitrary server-local file read and exfiltration in MCP Atlassian (sooperset/mcp-atlassian) prior to 0.22.0 lets an aut
Path traversal in the MCP Atlassian server (mcp-atlassian) prior to 0.22.0 allows an authenticated MCP client to read fi
EUVD-2026-120865
NVD
CVE.org
GitHub
VulDB
Exploit-DB