CVE-2026-73497: MCP Atlassian is a Model Context Protocol (MCP): DNS-rebinding TOCTOU bypass of the SSRF fix (CVE-2026-27826): unauthenticated SSRF to cloud metadata
MCP Atlassian is a Model Context Protocol (MCP) server for Atlassian products (Confluence and Jira). From 0.17.0 until 0.22.0, validateurlforssrf resolves the attacker-controlled X-Atlassian-Jira-Url and X-Atlassian-Confluence-Url header host once at middleware time, but the outbound request is built with the raw hostname and resolves it again at connection time with no IP pinning. An attacker-controlled DNS-rebinding name can return a public IP during validation and 169.254.169.254 or another internal IP during connection, enabling unauthenticated server-side requests to cloud metadata or internal services. The flaw spans src/mcpatlassian/utils/urls.py, src/mcpatlassian/servers/main.py, and src/mcpatlassian/servers/dependencies.py; validateurlforssrf returns only a verdict rather than a pinned IP, UserTokenMiddleware processes the attacker-controlled headers before fetcher creation, and the Jira and Confluence fetchers use the raw hostname. This issue is fixed in version 0.22.0.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
MCP Atlassianto a version that resolves this vulnerability.Fixed in 0.22.0 - Compensating control
If you cannot upgrade immediately, block or restrict outbound access from the MCP Atlassian server to internal and link-local IP ranges (including 169.254.169.254) and other internal services to mitigate DNS-rebinding SSRF via attacker-controlled X-Atlassian-Jira-Url and X-Atlassian-Confluence-Url headers.
Event History
Frequently Asked Questions
Which deployments are affected?
MCP Atlassian versions from 0.17.0 up to, but not including, 0.22.0 are affected. The issue applies to deployments that accept attacker-controlled X-Atlassian-Jira-Url or X-Atlassian-Confluence-Url headers.
What does an attacker need to exploit this issue?
An attacker does not need authentication or user interaction. They need to supply one of the affected URL headers with a DNS-rebinding hostname that resolves to a public IP during validation and to a cloud metadata or internal IP address when the server makes the outbound connection.
Are default SSRF protections sufficient?
No. The affected validation checks the hostname resolution only once, while the outbound Jira or Confluence fetcher resolves the raw hostname again without pinning the validated IP address. This allows DNS rebinding to bypass the validation result.
What should be done if upgrading is not immediately possible?
The provided data identifies the attacker-controlled Jira and Confluence URL headers as the input path. Restricting or removing untrusted access to X-Atlassian-Jira-Url and X-Atlassian-Confluence-Url can reduce exposure until version 0.22.0 can be deployed.
How can I determine whether a deployment is vulnerable?
Check the MCP Atlassian version: releases before 0.17.0 and version 0.22.0 are not identified as affected, while versions 0.17.0 through 0.21.0 are. Also determine whether untrusted clients can submit the affected URL headers to the server.