Description

MCP Atlassian is a Model Context Protocol (MCP) server for Atlassian products (Confluence and Jira). From 0.17.0 until 0.22.0, validate_url_for_ssrf 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/mcp_atlassian/utils/urls.py, src/mcp_atlassian/servers/main.py, and src/mcp_atlassian/servers/dependencies.py; validate_url_for_ssrf 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.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "6.5",
  "pubDate": "2026-09-14T20:16:50.993Z",
  "pubdate": "2026-09-14T20:16:50.993Z",
  "executiveSummary": "MCP Atlassian versions 0.17.0 through 0.22.0 are susceptible to a Server-Side Request Forgery (SSRF) vulnerability due to inconsistent DNS resolution handling.\nThe vulnerability arises from a time-of-check to time-of-use (TOCTOU) discrepancy between the validation logic and the final connection request.\nAn unauthenticated attacker can exploit this via DNS rebinding, forcing the server to resolve a domain to a benign public IP address during validation and subsequently to an internal or sensitive cloud metadata IP address (e.g., 169.254.169.254) during the actual outbound request.\nThis flaw enables unauthorized access to internal network resources, cloud metadata services, and local infrastructure that should be inaccessible to the application.\nThe risk is critical as it bypasses intended security controls at the middleware layer, permitting arbitrary requests to internal network segments.\nExploitation requires the attacker to control the target host provided via the X-Atlassian-Jira-Url or X-Atlassian-Confluence-Url headers.",
  "technicalDetails": "The vulnerability is rooted in a flaw within the URL validation architecture located in src/mcp_atlassian/utils/urls.py, src/mcp_atlassian/servers/main.py, and src/mcp_atlassian/servers/dependencies.py.\nThe validate_url_for_ssrf function performs a DNS resolution check at middleware time to verify the provided host. However, it returns only a boolean verdict rather than pinning the resolved IP address for the subsequent fetcher connection.\nThe UserTokenMiddleware parses attacker-supplied X-Atlassian-Jira-Url and X-Atlassian-Confluence-Url headers before the fetcher instance is created. Because the fetcher uses the raw hostname rather than a validated or pinned IP, a second DNS resolution occurs when the fetcher establishes the outbound connection.\nThis creates a classic TOCTOU race condition known as DNS rebinding. An attacker can craft a malicious DNS record with a very low Time-To-Live (TTL). When validate_url_for_ssrf queries the DNS, the attacker returns a public, non-restricted IP address, causing the validation check to pass.\nWhen the Jira or Confluence fetcher subsequently initiates the connection, the system resolves the hostname again. By this time, the attacker updates the DNS record to point to an internal resource, such as the cloud instance metadata service at 169.254.169.254, or other internal services within the local network.\nBecause the final connection logic does not enforce the validated IP or apply additional egress filtering, the fetcher proceeds to make a request to the restricted internal destination. This allows an attacker to exfiltrate data from metadata services, interact with internal APIs, or probe internal network segments.\nThe vulnerability impacts all instances using MCP Atlassian versions 0.17.0 up to 0.22.0. The lack of connection-time IP pinning ensures that any hostname-based validation is insufficient to mitigate against DNS rebinding attacks in this implementation."
}