CVE-2026-77246 is a high severity (7.4) flaw in MCP Atlassian before 0.22.0. In an HTTP deployment with READ_ONLY_MODE false, a caller without an Authorization identity could choose the Atlassian URL by header and make the attachment tool send a server-local file there. Upgrade to 0.22.0.
What's affected
The record and the GitHub advisory both say MCP Atlassian before 0.22.0 is affected, and 0.22.0 is the patched version. The record's conditions: an HTTP transport deployment, READ_ONLY_MODE set to false, and a request that arrives without an Authorization identity.
The advisory adds that the attacker-supplied Atlassian service headers can name a public attacker host, or a host allowed by MCP_ALLOWED_URL_DOMAINS, and that the Docker container hostnames in that allow list can pass the URL check.
Where sources differ. The record scores this 7.4 High with an adjacent network vector and changed scope. The GitHub advisory text we read does not give a different number, but it calls the same family of issue High, and Critical in deployments driven by an LLM or prompt injection. Both sources agree on 0.22.0.
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. 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.
- Do not expose the HTTP transport to untrusted callers. Put authentication in front of it.
- Keep READ_ONLY_MODE set to true where uploads are not needed. The record's conditions require it to be false.
- Review MCP_ALLOWED_URL_DOMAINS and remove hosts you do not control.
- Rotate any secrets stored in files readable by the server process if you suspect it was reachable by untrusted callers.
Why it matters
Several small gaps line up here. The server took Atlassian service headers from a request that carried no Authorization identity. Its URL check blocked private ranges but not an attacker-controlled public host. And the attachment tool accepted a file path on the server's own disk. Together they let a caller point the upload at their own host and name a local file. The record files this under CWE-200, CWE-22 and CWE-441, which cover exposure of sensitive information, path traversal and an unintended proxy. Gold lists them at CWE-200, CWE-22, CWE-441.
The lesson reaches past one project. MCP servers often run with more file and network access than the people calling them realize, and a tool that accepts a path is a tool that reads the disk. The record does not mark it as a CISA KEV entry.
Try it yourself
Click through it at your own pace, or open it full screen.
Quick check
Does stdio use avoid this?
The record and advisory describe HTTP transport deployments. Confirm in the advisory for your setup, and upgrade regardless.
What must be true to be exposed?
HTTP transport, READ_ONLY_MODE set to false, and a caller who can reach the server without an Authorization identity, per the record.
Sources
- MCP Atlassian advisory GHSA-wv8v-v4c5-v75j
- MCP Atlassian release v0.22.0
- MCP Atlassian pull request 1448
Last reviewed: 18 October 2026.
