CVE-2026-77261 is a high severity (CVSS 7.1) server-side request forgery flaw in MCP Atlassian, the Model Context Protocol server for Jira and Confluence. Basic-auth and OAuth sessions skip the redirect check in versions before 0.22.0. The fix is version 0.22.0, so upgrade and review which authentication modes you run.
What's affected
MCP Atlassian (package name mcp-atlassian, from the sooperset project) in every version before 0.22.0. The fixed version is 0.22.0. The advisory describes this as an incomplete fix for an earlier SSRF issue (GHSA-7r34-79r5-rcc9), so an older patched build may still be exposed here.
The weakness sits in how the server builds HTTP sessions. The advisory says three authentication branches create a fetcher, and only the header personal access token branch attached the redirect guard. The basic-auth branch and the OAuth or PAT branch did not. Those are the setups most production deployments use.
How to check if you're exposed
MCP Atlassian is a Python package, so the installed version is the thing to read. In the environment that runs the server, check it with pip.
pip show mcp-atlassian
pip list | grep -i mcp-atlassian
If you run it through uvx or a container image, look at the pinned tag in your launch command, compose file or deployment manifest. Anything below 0.22.0 is in range. Also note which authentication modes you use and whether the server is reachable over HTTP by clients you do not fully trust, because the advisories tie each issue to specific entry points.
What to do now
- Upgrade mcp-atlassian to 0.22.0 or later. The maintainers fixed all four related issues in that release (see the release notes and pull request 1448).
- Redeploy every place that runs the server: local developer setups, shared containers and any agent platform that bundles it. Confirm the new version with pip show afterward.
- If you cannot upgrade today, restrict outbound network access for the host or container running the server so it cannot reach cloud metadata addresses or internal ranges, and only point it at Atlassian instances you control.
- Rotate any Atlassian tokens and cloud credentials that this server could reach if you have logs suggesting it contacted unexpected internal addresses.
Why it matters
The class of weakness is CWE-918, server-side request forgery. The server was built to call an Atlassian site, and a redirect is a normal thing for a web server to return. A guard existed to check the destination of each redirect, but it was not attached to two of the three session types, so a redirect to an internal address was followed without a second look.
The advisory notes the attacker needs control of, or a compromise of, the Atlassian instance the server is configured to talk to. That is why the record rates attack complexity as high, yet the scope change in the vector reflects that the request can land on a different trust zone than the one the server normally touches. The record does not mark this CVE as exploited in the wild, and the sources do not say it is.
You can also run a free in-browser dependency scan at gold.safeguard.sh/scan to see whether the affected component appears in your project, and reachability analysis helps separate code paths you actually call from ones you only ship.
Try it yourself
Click through it at your own pace, or open it full screen.
Quick check
Does this affect me if I only use the header token mode?
The advisory says the redirect guard was attached in that branch, so this specific issue is about the basic-auth and OAuth branches. Other CVEs fixed in 0.22.0 do touch the header flow, so upgrade anyway.
Is it being exploited?
The record's KEV flag is false and neither source reports exploitation. Treat it as a patch-soon item, not an emergency.
Sources
Last reviewed: 18 October 2026.
