CVE-2026-73497: MCP Atlassian DNS Rebinding SSRF Vulnerability

CVE-2026-73497 Overview

CVE-2026-73497 is a Server-Side Request Forgery (SSRF) vulnerability in MCP Atlassian, a Model Context Protocol (MCP) server for Atlassian Confluence and Jira. Affected versions span 0.17.0 through 0.21.x. The flaw allows an unauthenticated attacker to exploit DNS rebinding against attacker-controlled X-Atlassian-Jira-Url and X-Atlassian-Confluence-Url headers. The validate_url_for_ssrf function returns only a verdict without pinning the resolved IP, so the outbound request resolves the hostname a second time at connection. This time-of-check to time-of-use gap enables requests to internal services such as cloud metadata endpoints. The issue is fixed in version 0.22.0.

Critical Impact
Unauthenticated attackers can coerce the MCP server into issuing requests to internal endpoints, including 169.254.169.254 cloud metadata, exposing credentials and internal service data.

Affected Products

MCP Atlassian 0.17.0 through 0.21.x
Deployments exposing the MCP server to untrusted network clients
Environments hosting the server on cloud instances with metadata service access

Discovery Timeline

2026-09-14 - CVE-2026-73497 published to the National Vulnerability Database
2026-09-15 - Last updated in NVD database

Technical Details for CVE-2026-73497

Vulnerability Analysis

The vulnerability is a classic Time-of-Check to Time-of-Use (TOCTOU) SSRF triggered by DNS rebinding [CWE-918]. The UserTokenMiddleware in src/mcp_atlassian/servers/main.py processes the attacker-controlled X-Atlassian-Jira-Url and X-Atlassian-Confluence-Url headers before fetcher creation. The middleware invokes validate_url_for_ssrf in src/mcp_atlassian/utils/urls.py, which resolves the hostname and returns a boolean verdict. It does not return or pin the validated IP address.

The Jira and Confluence fetchers, wired through src/mcp_atlassian/servers/dependencies.py, then build the outbound HTTP request using the raw hostname string. The underlying HTTP client performs a fresh DNS lookup at connection time. An attacker who controls an authoritative DNS server can return a public IP for the first query and a private IP for the second. The attack requires no authentication but has high complexity because the attacker must coordinate DNS response timing.

Root Cause

The root cause is a validation contract that returns a verdict rather than a pinned resolution. validate_url_for_ssrf treats DNS as trusted between the check and the use, ignoring that a caller can rebind the name.

Attack Vector

The attacker points the header at a hostname under their control. The name resolves to a public IP during middleware validation, then to 169.254.169.254 or another internal address when the fetcher connects. The MCP server then issues an authenticated-looking request to the internal target and returns the response to the caller.

No code examples are published beyond the upstream patch. See the GitHub Security Advisory GHSA-489g for further technical detail.

Detection Methods for CVE-2026-73497

Indicators of Compromise

Inbound HTTP requests to the MCP server containing X-Atlassian-Jira-Url or X-Atlassian-Confluence-Url headers pointing to hostnames outside expected Atlassian domains.
Outbound connections from the MCP server host to link-local metadata addresses such as 169.254.169.254 or RFC1918 ranges.
DNS query patterns showing repeated resolutions of the same hostname within seconds returning different IP addresses.

Detection Strategies

Log and inspect all values of the X-Atlassian-Jira-Url and X-Atlassian-Confluence-Url headers at the ingress layer.
Alert on any outbound HTTP request from MCP Atlassian process contexts to non-Atlassian destinations.
Correlate DNS resolver logs against MCP Atlassian egress flows to identify rebinding-style TTL and answer variance.

Monitoring Recommendations

Deploy egress firewall rules that block MCP Atlassian workloads from reaching link-local and internal-only ranges.
Enable cloud metadata service protections such as IMDSv2 on AWS and equivalent header-based auth on Azure and GCP.
Forward MCP server access logs and process network telemetry into a SIEM for behavioral analysis of header values and destinations.

How to Mitigate CVE-2026-73497

Immediate Actions Required

Upgrade MCP Atlassian to version 0.22.0 or later without delay.
Rotate any cloud instance credentials that may have been exposed through the metadata service if exploitation is suspected.
Restrict network access to the MCP Atlassian endpoint to trusted client networks only.

Patch Information

The fix is delivered in MCP Atlassian v0.22.0 and merged through Pull Request #1448. The remediation, in commit b041733, hardens SSRF handling so validation returns a pinned IP that is reused for the outbound connection, closing the DNS rebinding window.

Workarounds

Force IMDSv2 on AWS workloads to require a session token that DNS-rebinding SSRF cannot obtain in a single request.
Configure host firewall rules blocking outbound traffic from the MCP server to 169.254.0.0/16, 10.0.0.0/8, 172.16.0.0/12, and 192.168.0.0/16.
Terminate the MCP Atlassian service behind a proxy that strips or validates the X-Atlassian-Jira-Url and X-Atlassian-Confluence-Url headers against an allowlist.

bash

# Example iptables rule blocking metadata access from the MCP host
iptables -A OUTPUT -d 169.254.169.254 -j REJECT
iptables -A OUTPUT -d 10.0.0.0/8 -j REJECT
iptables -A OUTPUT -d 172.16.0.0/12 -j REJECT
iptables -A OUTPUT -d 192.168.0.0/16 -j REJECT