CVE-2026-77274 is a high severity (CVSS 8.2) SSRF bypass in MCP Atlassian, the Model Context Protocol server for Jira and Confluence. In versions before 0.22.0 a crafted URL passes validation as an external host while the HTTP client connects to an internal one. The fix is 0.22.0.
What's affected
MCP Atlassian in every version before 0.22.0. Fixed in 0.22.0. The GitHub advisory labels it high, with no numeric score visible on the page we fetched, so the 8.2 comes from the record.
The advisory places the flaw in the header-based Jira and Confluence URL authentication flow, where the caller supplies the Atlassian URL in a request header. The reporter tested a streamable HTTP deployment. Servers that only use fixed, locally configured URLs are not in that flow, but should still upgrade.
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.
- Until the upgrade lands, avoid exposing the HTTP endpoint to untrusted callers and deny the server access to loopback, link-local and private ranges.
- 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 cause is a parser disagreement, a close cousin of CWE-918, server-side request forgery. The validator used one library to work out which host a URL points to. The HTTP client used another set of rules for the same text. A backslash placed before something that looks like user information is read one way by the validator and another way by the client, so the validator approved a public name while the client dialed an internal address.
This pattern shows up in many projects. When two components parse the same string, any difference is a hole. The durable fix is to validate the exact address that will be connected to, which is what the project moved toward in this release. The record shows no exploitation reports and a false KEV flag.
Quick check
Is this the same as the DNS rebinding issue?
No. Both end in SSRF in the same flow, but this one is a parsing mismatch and the rebinding one is a timing gap on DNS answers. Both are fixed in 0.22.0.
Can I detect it from logs?
Look for outbound connections from the server host to internal or metadata addresses that you do not expect.
Sources
Last reviewed: 18 October 2026.
