CVE-2026-73497: MCP Atlassian: DNS rebinding SSRF reaches cloud metadata

MEDIUMPoC AVAILABLE

Published September 14, 2026

CISO Take

MCP Atlassian versions 0.17.0 through 0.21.x validate the attacker-supplied Jira and Confluence URL headers against SSRF rules once, then resolve the hostname again when the outbound request is made, so a DNS-rebinding domain can pass the check with a public IP and connect to 169.254.169.254 or internal services. The attack needs no authentication, but the high complexity (CVSS 6.5) and the DNS timing it requires keep exploitation likelihood low: EPSS is 0.00375 (top 71%), there is no public exploit, no Nuclei template, it is not in CISA KEV, and CISA SSVC says TRACK. Blast radius is limited (1 downstream dependent), but the package has 38 other CVEs and the server often runs near cloud workloads where metadata endpoints can expose instance credentials. Upgrade to 0.22.0 or later, and where MCP Atlassian is exposed over HTTP, enforce IMDSv2 with hop limit 1 and egress filtering until patched.

Sources:NVDEPSSGitHub AdvisoryATLASCISA SSVC

What is the risk?

Medium overall. Exploitation needs a DNS rebinding race (AC:H) but no privileges or user interaction. Confidentiality impact is high because cloud metadata or internal services could leak credentials, while integrity impact is low. Risk rises sharply for HTTP-transport deployments reachable from untrusted networks and running on cloud instances with attached IAM roles. Stdio/local-only deployments are much less exposed because attackers cannot supply the headers. No active exploitation or public PoC is known (SSVC: TRACK).

How does the attack unfold?

Initial Access

Attacker sends an unauthenticated request to the MCP Atlassian HTTP endpoint with a header pointing to a DNS-rebinding domain.

AML.T0049

Validation Bypass

validate_url_for_ssrf resolves the domain to a public IP and approves it, but does not pin the IP for the later connection.

Exploitation

The fetcher re-resolves the hostname, which now returns 169.254.169.254 or an internal IP, and the server connects to it.

Impact

Cloud metadata credentials or internal service data are exposed, enabling cloud account pivoting.

AML.T0055

Initial Access

Attacker sends an unauthenticated request to the MCP Atlassian HTTP endpoint with a header pointing to a DNS-rebinding domain.

AML.T0049

Validation Bypass

validate_url_for_ssrf resolves the domain to a public IP and approves it, but does not pin the IP for the later connection.

Exploitation

The fetcher re-resolves the hostname, which now returns 169.254.169.254 or an internal IP, and the server connects to it.

Impact

Cloud metadata credentials or internal service data are exposed, enabling cloud account pivoting.

AML.T0055

What systems are affected?

Package	Ecosystem	Vulnerable Range	Patched
MCP Atlassian	pip	—	No patch
2 dependents85% patched~4d to patchFull package profile →

Do you use MCP Atlassian? You're affected.

How severe is it?

CVSS 3.1

6.5 / 10

EPSS

0.4%

chance of exploitation in 30 days

Higher than 31% of all CVEs

Source: EPSS v3 — FIRST.org

Exploitation Status

Exploit Available

Exploitation: MEDIUM

Sophistication

Moderate

Exploitation Confidence

medium

○Public PoC indexed (trickest/cve)

Composite signal derived from CISA KEV, VulnCheck KEV, CISA SSVC, EPSS, Metasploit, Exploit-DB, trickest/cve, Nuclei templates, and inthewild.io exploitation reports.

What is the attack surface?

AVNetwork

ACHigh

PRNone

UINone

SUnchanged

CHigh

ILow

ANone

What should I do?

1 step

1) Upgrade mcp-atlassian to 0.22.0 or later (fix in PR #1448, commit b041733). 2) If you can't patch immediately, don't expose the HTTP transport to untrusted networks; require authentication or a gateway in front of it, and strip or allowlist the X-Atlassian-Jira-Url and X-Atlassian-Confluence-Url headers to known Atlassian hosts. 3) Enforce IMDSv2 with hop limit 1 (or block metadata access) and apply egress filtering that denies link-local, RFC1918 and loopback destinations from the MCP server. 4) Run the server with least-privilege IAM roles or no instance role. 5) Detect: alert on outbound connections from the MCP host to 169.254.169.254 or internal ranges, and on unusual or short-TTL domains in the Atlassian URL headers or DNS logs. 6) Rotate any cloud credentials if suspicious metadata access is found.

What does CISA's SSVC say?

DecisionTrack

Exploitationnone

AutomatableNo

Technical Impactpartial

Source: CISA Vulnrichment (SSVC v2.0). Decision based on the CISA Coordinator decision tree.

How is it classified?

Data LeakageData ExtractionAgentPluginAPIAML.T0049- Exploit Public-Facing Application AML.T0055- Unsecured Credentials AML.T0075- Cloud Service Discovery

Which compliance frameworks are affected?

This CVE is relevant to:

EU AI Act

Art. 15-Accuracy, robustness and cybersecurity

ISO 42001

A.10.3-Suppliers

NIST AI RMF

MANAGE 2.3-Response to previously unknown risks and mitigation

OWASP LLM Top 10

LLM03-Supply ChainLLM06-Excessive Agency

Frequently Asked Questions

What is CVE-2026-73497?

Is CVE-2026-73497 actively exploited?

Proof-of-concept exploit code is publicly available for CVE-2026-73497, increasing the risk of exploitation.

How to fix CVE-2026-73497?

1) Upgrade mcp-atlassian to 0.22.0 or later (fix in PR #1448, commit b041733). 2) If you can't patch immediately, don't expose the HTTP transport to untrusted networks; require authentication or a gateway in front of it, and strip or allowlist the X-Atlassian-Jira-Url and X-Atlassian-Confluence-Url headers to known Atlassian hosts. 3) Enforce IMDSv2 with hop limit 1 (or block metadata access) and apply egress filtering that denies link-local, RFC1918 and loopback destinations from the MCP server. 4) Run the server with least-privilege IAM roles or no instance role. 5) Detect: alert on outbound connections from the MCP host to 169.254.169.254 or internal ranges, and on unusual or short-TTL domains in the Atlassian URL headers or DNS logs. 6) Rotate any cloud credentials if suspicious metadata access is found.

What systems are affected by CVE-2026-73497?

This vulnerability affects the following AI/ML architecture patterns: agent frameworks, MCP servers, tool-calling AI agents, cloud-hosted AI services.

What is the CVSS score for CVE-2026-73497?

CVE-2026-73497 has a CVSS v3.1 base score of 6.5 (MEDIUM). The EPSS exploitation probability is 0.38%.

What is the AI security impact?

Affected AI Architectures

agent frameworksMCP serverstool-calling AI agentscloud-hosted AI services

MITRE ATLAS Techniques

AML.T0049Exploit Public-Facing Application

AML.T0055Unsecured Credentials

AML.T0075Cloud Service Discovery

Compliance Controls Affected

EU AI Act: Art. 15

ISO 42001: A.10.3

NIST AI RMF: MANAGE 2.3

OWASP LLM Top 10: LLM03, LLM06

What are the technical details?

Original Advisory

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.

Exploitation Scenario

An attacker finds an internet-reachable MCP Atlassian server running in HTTP mode on a cloud VM. They register a domain with an authoritative DNS server that returns a public IP with a very short TTL for the first lookup and then 169.254.169.254 for the next. They send a request with X-Atlassian-Jira-Url set to that domain. The SSRF validator resolves it to the public IP and approves it, but the fetcher then re-resolves it at connection time, reaches the metadata service and retrieves instance role credentials or internal service data. The attacker then uses the stolen credentials to pivot into the victim's cloud account.

Weaknesses (CWE)

CWE-918Server-Side Request Forgery

CWE-918 — Server-Side Request Forgery: The web server receives a URL or similar request from an upstream component and retrieves the contents of this URL, but it does not sufficiently ensure that the request is being sent to the expected destination.

[Implementation, Operation] If there is a known list of applications, IP, hostname, and/or domains to which the product is allowed to communicate, then use allowlists to ensure that outgoing requests are restricted to these known entities. The allowlists could be in the application code or possibly enforced by firewalls or network segmentation [REF-1511].
[Implementation, Operation] If the product is expected to be able to connect to arbitrary IP addresses or domains, consider using a denylist that includes private network addresses, internal domain names, etc. The denylist could be in the application code or possibly enforced by firewalls or network segmentation [REF-1511].

Source: MITRE CWE corpus.