MCP Atlassian EUVD-2026-84627

Requires the mcp-atlassian server (prior to v0.22.0) to be reachable by the attacker over a transport where it will fetch a caller-influenced URL, and the attacker must control authoritative DNS for a hostname to serve a short-lived (low-TTL) answer that is public at validation time and private at connection time. Exploitation succeeds only if the server's network can actually reach a valuable internal or metadata target (e.g. cloud IMDS at 169.254.169.254 or internal services) once rebound. No authentication is required (PR:N), but the DNS-rebinding race raises complexity (AC:H) and success is not guaranteed on any single attempt; environments already on v0.22.0, or with no reachable internal/metadata endpoints, are not exploitable.

This is a genuine but conditional SSRF issue, not a high-CVSS-but-hollow finding. The provided CVSS 3.1 vector (AV:N/AC:H/PR:N/UI:N/S:C/C:H/I:L/A:N, base 7.5) reflects the core danger: network-reachable, unauthenticated (PR:N), scope-changing (the MCP server is coerced into reaching internal/cloud-metadata systems it fronts), with high confidentiality loss (C:H) but only low integrity and no availability impact. The AC:H is well-justified - the attack is a Time-of-Check/Time-of-Use race (CWE-367) requiring the attacker to serve a short-lived DNS answer that is public during validate_url_for_ssrf and private at socket connect time, i.e. classic DNS rebinding. Signals are consistent rather than conflicting: no EPSS score, no CISA KEV listing, and no public POC were provided, so exploitation status is 'no public exploit identified at time of analysis.' The one caveat worth flagging is that this vuln specifically defeats the earlier CVE-2026-27826 remediation, meaning an environment believed to be patched against SSRF may still be exposed - teams tracking only the prior CVE would miss this. Overall this is a real priority for anyone running mcp-atlassian over a network-exposed transport with reachable internal/metadata endpoints (e.g. cloud IMDS), but the race-condition complexity and niche product footprint temper the urgency relative to the 7.5 rating.

An attacker sends the MCP server a URL whose hostname they control via authoritative DNS with a very low TTL; validate_url_for_ssrf resolves it to a public address and passes the SSRF check, but by the time Requests/urllib3 re-resolves to actually connect, the attacker's DNS now answers with an internal or cloud-metadata address (e.g. 169.254.169.254), so the server fetches attacker-chosen internal content and returns it. Because the flow is unauthenticated (PR:N), any network client that can reach the server can attempt this. No public exploit code was identified at time of analysis, though the advisory documents the exact vulnerable code path (validate_url_for_ssrf → _check_dns_resolution → socket.getaddrinfo → _make_ssrf_safe_hook).