A path traversal vulnerability in the sooperset mcp-atlassian Model Context Protocol (MCP) server allowed authenticated remote attackers to read arbitrary files from the host system. The flaw affected versions up to 0.24.0 and was fixed in version 0.24.1 released on November 8, 2026.
Quick Take
- What: Path traversal in
validate_safe_pathfunction insrc/mcp_atlassian/utils/io.pyallows arbitrary file read - Who is affected: Remote HTTP/SSE deployments of mcp-atlassian up to 0.24.0 started from a wide working directory (systemd default root or user home)
- CVSS: 4.3 (Medium)
- Fixed in: Version 0.24.1
- What to do: Upgrade to mcp-atlassian 0.24.1 or later
In plain English
The mcp-atlassian tool helps AI assistants talk to Atlassian products like Jira and Confluence. A security flaw let someone who could connect to a remote mcp-atlassian server read any file the server could see, including passwords and secret keys. The problem only affected servers running over the network (HTTP or SSE mode), not local desktop setups.
What you should do: If you run mcp-atlassian on a server, update to version 0.24.1. If you only use it on your own computer with Claude Desktop or Cursor, you do not need to do anything.
What happened
The vulnerability resided in the validate_safe_path function in src/mcp_atlassian/utils/io.py. This function was meant to confine file paths to the server’s working directory, preventing attackers from reading files outside that boundary. However, when the server process started from a wide working directory such as / (the systemd default for system units) or the user’s home directory (the default for systemd user units), the guard became ineffective.
An authenticated remote MCP caller could invoke the confluence_upload_attachment or jira_upload_attachment tools with a file_path parameter pointing to any file readable by the server process, such as /etc/passwd, /proc/self/environ (containing Atlassian API tokens), .env files, or SSH keys. The server would read the file and upload it to the caller’s own Confluence or Jira instance, effectively exfiltrating the data.
The project’s official documentation for remote deployment told operators to run uvx mcp-atlassian --transport streamable-http with no working-directory requirement, and nothing in the package changed or validated the working directory at startup. The vulnerability was publicly disclosed in GitHub Security Advisory GHSA-qh7q-jmc7-rc7j and assigned CVE-2026-124503.
The flaw was part of a coordinated security audit that resulted in multiple advisories consolidated by root cause. The fix landed in pull request #1448, which introduced a dedicated file directory (MCP_ATLASSIAN_FILES_DIR or ~/.mcp-atlassian/files) for HTTP and SSE transports, replacing the implicit reliance on the process working directory.
What you should do
Upgrade to mcp-atlassian version 0.24.1 or later. The fixed version is available via uvx mcp-atlassian or pip install mcp-atlassian==0.24.1.
After upgrading, note that on HTTP and SSE transports, tools that read or write server files now use the directory specified by the MCP_ATLASSIAN_FILES_DIR environment variable, or ~/.mcp-atlassian/files if unset. The server will refuse to start if that directory is / or your home directory. The stdio transport (local desktop use) is unchanged.
If you run mcp-atlassian in a systemd unit, Docker container, or shell launch for remote access, verify that your deployment uses version 0.24.1. The official Docker image was already protected because it set WORKDIR /app.
What it means
This vulnerability highlights the risk of implicit security boundaries in agent frameworks. The validate_safe_path function performed correct symlink resolution and ../ rejection, but its boundary (the process working directory) was an environment property never explicitly chosen by operators. The same root cause had already been identified on the download side in CVE-2026-77271 (GHSA-6vmq-24h2-pj7j), whose suggested fix was to pass a dedicated, explicitly configured directory instead of relying on the current working directory.
The affected population was non-containerized remote deployments: systemd units without an explicit WorkingDirectory= directive, and shell or uvx launches from a wide directory. Local stdio deployments (Claude Desktop, Cursor) were not vulnerable because the project states that local file reads are intended behavior in that context.
The fix in version 0.24.1 introduced an explicit file directory for remote transports, removed the working-directory dependency, and added startup validation to reject unsafe directory choices. The release also fixed multiple related issues in the same security audit, including HTTP transport authentication bypass, SSRF hardening, project and space filter enforcement, and OAuth token file permissions.
