CVE-2026-77260 is a high severity (7.5) path traversal in MCP Atlassian before 0.22.0. The Confluence and Jira upload_attachment tools accept any file_path and open the file on the server, so a permitted caller can upload sensitive host files and read them back. Upgrade to 0.22.0.
What's affected
The record and the GitHub advisory both say versions before 0.22.0 are affected, with 0.22.0 the patched release. Both the Confluence and Jira attachment paths are involved.
The advisory describes this as the read-direction counterpart of CVE-2026-27825, an earlier file write issue that the project had already fixed. The record says a permitted MCP caller is enough, which means anyone or anything allowed to call the tool.
Where sources differ. The record scores this 7.5 High. The reporter's advisory text says High, and Critical in deployments driven by an LLM or prompt injection, which is a statement about context and not a different base score. Both give 0.22.0 as the fix.
How to check if you're exposed
Find the version of the server wherever it runs:
pip show mcp-atlassian
uv pip show mcp-atlassian
docker image ls | grep -i atlassian
Anything below 0.22.0 is affected. Then check how it is deployed. Per the advisories, the exposed setup is HTTP transport (streamable-http or sse), not a local stdio setup, and READ_ONLY_MODE set to false. Find who or what can reach the HTTP port: other containers, other hosts, a gateway, or agents driven by prompts. Also list which agents, users and automations can call the attachment tools, since any permitted caller is in scope. A dependency scan is the quickest way to find this kind of component across many projects. Safeguard's free in-browser scan at gold.safeguard.sh/scan checks your dependencies against known CVEs, and reachability analysis helps you separate libraries your code actually calls from ones that only sit in the tree.
What to do now
- Upgrade MCP Atlassian to 0.22.0 or later.
- Restrict which callers can use the attachment tools, especially agents that act on untrusted input.
- Run the server as a low-privilege user with access only to the files it needs.
- Keep secrets such as environment files, SSH keys and cloud credentials out of paths the server process can read.
- Review Confluence and Jira attachment history for uploads you do not recognize.
Why it matters
The upload tool accepted an unconstrained file_path and opened whatever it pointed to. That is path traversal, filed under CWE-22. A caller who could invoke the tool could name a file such as a credentials file, upload it to an Atlassian destination, and then retrieve it. The project fixed the write direction earlier and the read direction was left open, the record's linked advisory says.
This matters most where an AI agent calls the tool. An agent that reads untrusted text, such as a ticket or a web page, can be tricked into calling a tool with a path the human never intended. That is why the reporter rates it higher for LLM-driven deployments. Constraining the path in the tool is the right fix, and least privilege on the host limits the damage even when a tool is wrong. The record does not mark it as a CISA KEV entry.
Quick check
Why does an AI agent raise the risk?
An agent that processes untrusted content can be induced to call the upload tool with a sensitive local path. The reporter calls it Critical in such deployments.
What fixes it?
Upgrading to MCP Atlassian 0.22.0 or later, which constrains the path.
Sources
- MCP Atlassian advisory GHSA-f4p7-qx46-wc5j
- MCP Atlassian release v0.22.0
- MCP Atlassian pull request 1448
Last reviewed: 18 October 2026.
