CVE-2026-77265 is a medium severity (CVSS 5.9) DNS rebinding flaw in MCP Atlassian, the Model Context Protocol server for Jira and Confluence. It affects versions before 0.22.0 when URLs arrive in request headers. The fix is 0.22.0. Upgrade and restrict outbound access from the host.
What's affected
MCP Atlassian in every version before 0.22.0. Fixed in 0.22.0. The GitHub advisory rates it medium at 5.9, which matches the record.
The advisory limits the exposure to deployments that accept a Jira or Confluence URL in the X-Atlassian-Jira-Url or X-Atlassian-Confluence-Url request headers together with a header-based personal access token. If you only ever configure fixed URLs through environment variables, the entry point described in the advisory is not in your path, though upgrading is still sensible.
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.
Then check whether your clients send the two URL headers named above. If your gateway or agent framework sets them per request, you are in the described path.
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 the server must stay on an older build for a while, stop accepting caller-supplied Jira and Confluence URLs, and block the host from reaching 127.0.0.1, link-local and private address ranges at the network layer.
- 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
This is CWE-918, server-side request forgery, through a validate-then-use gap. The server looked up the hostname, confirmed the answer was a public address, and then made the real request later. The HTTP client resolved the name a second time. A hostname that answers with a public address first and an internal address second passes the check and still reaches the internal service.
The advisory calls the attack probabilistic, since the timing has to line up, which is why complexity is high. The advisory's suggested fix, resolve once and connect to that address, is the standard cure for this pattern. No unauthenticated exploitation reports are cited, and the KEV flag in the record is false.
Quick check
Why does validating the URL first not help?
Because the name is resolved again when the connection is made. The answer can change in between, so the check and the use see different addresses.
Is a network-level block enough?
It reduces the damage a lot, since internal and metadata addresses become unreachable, but the fix is still the upgrade.
Sources
Last reviewed: 18 October 2026.
