CVE-2026-73497: 
Python vulnerability analysis and mitigation

CVE-2026-73497 is a DNS-rebinding Time-of-Check Time-of-Use (TOCTOU) Server-Side Request Forgery (SSRF) vulnerability in the mcp-atlassian Model Context Protocol (MCP) server for Atlassian products (Confluence and Jira). It affects versions 0.17.0 through 0.21.x (i.e., >= 0.17.0, < 0.22.0) and was disclosed on September 14, 2026, with a fix released in version 0.22.0 on July 10, 2026. The vulnerability allows unauthenticated attackers to bypass the existing SSRF guard (introduced in GHSA-7r34-79r5-rcc9) via DNS rebinding, enabling server-side requests to cloud metadata endpoints or internal services. It carries a CVSS v3.1 base score of 6.5 (Medium) (GitHub Advisory, Feedly).

The root cause is CWE-918 (Server-Side Request Forgery) compounded by CWE-367 (TOCTOU Race Condition). The validate_url_for_ssrf function in src/mcp_atlassian/utils/urls.py resolves the attacker-controlled X-Atlassian-Jira-Url or X-Atlassian-Confluence-Url request header's hostname once at middleware time and validates it against an IP allowlist, but returns only a string verdict — not a pinned IP address. The Jira and Confluence fetchers in src/mcp_atlassian/servers/dependencies.py subsequently build outbound requests using the raw (unpinned) hostname, which triggers a second DNS resolution at connection time. An attacker operating a fast-rebinding DNS server can return a globally routable IP during the validation lookup (causing the guard to pass) and then return 169.254.169.254 or another internal/metadata IP during the connection-time lookup, achieving unauthenticated SSRF. The flaw spans utils/urls.py, servers/main.py, and servers/dependencies.py (GitHub Advisory, Fix PR #1448).

Successful exploitation allows an unauthenticated attacker to make the MCP server issue arbitrary HTTP requests to cloud instance metadata services (e.g., 169.254.169.254 on AWS/GCP/Azure) or other internal network services not intended to be publicly accessible. This can result in exfiltration of cloud IAM credentials, internal service tokens, and other sensitive metadata, leading to high confidentiality impact. Integrity impact is rated low, and there is no direct availability impact. In cloud-hosted deployments, stolen IAM credentials could enable lateral movement to other cloud resources (GitHub Advisory, Feedly).

A proof-of-concept (PoC) was developed and executed by the reporter (daniel-mertz), demonstrating the structural TOCTOU bypass by simulating two separate getaddrinfo calls — one returning a public IP (passing validation) and one returning 169.254.169.254 (the actual connection target). The PoC loads the real urls.py code and proves the missing IP-pin structurally; a live end-to-end exploit additionally requires an attacker-controlled fast-rebinding authoritative DNS server to win the resolve-to-connect timing window. No in-the-wild exploitation has been reported, and the vulnerability is not listed in the CISA KEV catalog. The EPSS score is 0.0, reflecting low current exploitation probability (GitHub Advisory, Feedly).

1. Reconnaissance: Identify internet-exposed mcp-atlassian MCP server instances running versions 0.17.0–0.21.x in HTTP (streamable-http) mode, where the X-Atlassian-Jira-Url or X-Atlassian-Confluence-Url headers are processed by UserTokenMiddleware.
2. Set up a DNS rebinding server: Configure an attacker-controlled authoritative DNS server for a domain (e.g., rebind.attacker.example) with a very short TTL. Program it to return a globally routable public IP (e.g., 93.184.216.34) on the first query and 169.254.169.254 (or another internal IP) on subsequent queries.
3. Send a crafted request: Issue an unauthenticated HTTP request to the MCP server with the header X-Atlassian-Jira-Url: http://rebind.attacker.example (or the Confluence equivalent). The middleware calls validate_url_for_ssrf, which resolves the hostname and receives the public IP — validation passes.
4. Win the rebinding race: Before the fetcher makes its outbound connection, the DNS TTL expires. When the fetcher re-resolves rebind.attacker.example at connect time, the attacker's DNS server now returns 169.254.169.254.
5. Exfiltrate metadata: The MCP server connects to 169.254.169.254 (the cloud metadata endpoint), and the attacker receives the response — potentially including IAM role credentials, access tokens, or other sensitive instance metadata (GitHub Advisory, Fix PR #1448).

• Network: Outbound HTTP requests from the MCP server to 169.254.169.254 or other RFC 1918/link-local addresses (e.g., 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16, 169.254.0.0/16); DNS queries for short-TTL domains resolving to public IPs followed immediately by queries resolving to private/metadata IPs.
• Logs: MCP server access logs showing requests with X-Atlassian-Jira-Url or X-Atlassian-Confluence-Url headers containing external or unusual hostnames from unauthenticated or low-privilege callers; HTTP client error logs indicating connections to unexpected IP addresses.
• Process: Unusual outbound network connections initiated by the mcp-atlassian Python process to cloud metadata IP ranges, particularly 169.254.169.254:80.

The fix is available in mcp-atlassian version 0.22.0, released July 10, 2026. The patch introduces a SsrfPinningAdapter — a custom requests transport adapter that resolves each hostname exactly once, validates the resolved IP as globally routable, and connects to that same validated address, eliminating the possibility of DNS rebinding between validation and connection. The hostname is preserved for TLS SNI and certificate verification. Operator-configured hosts (JIRA_URL, CONFLUENCE_URL, MCP_ALLOWED_URL_DOMAINS) are exempt from the non-global-address rejection to preserve on-premises Data Center deployments. Users should upgrade to version 0.22.0 immediately; no configuration-only workaround is available for the DNS-rebinding bypass (GitHub Release v0.22.0, Fix PR #1448, Fix Commit).

The vulnerability was reported by security researcher daniel-mertz and disclosed via GitHub Security Advisories alongside a coordinated security audit that resolved 37 advisories in the v0.22.0 release. The maintainer (sooperset) acknowledged the incomplete fix of the prior SSRF advisory (GHSA-7r34-79r5-rcc9) and merged a comprehensive security hardening PR (#1448) that addressed this and numerous other issues simultaneously. The release notes explicitly credit the reporter and note contributions from @failsafesecurity and @rober15 for overlapping public reports (GitHub Advisory, GitHub Release v0.22.0).