MCP Atlassian CVE-2026-77265

Requires a deployment of MCP Atlassian (< 0.22.0) that accepts header-based Personal Access Token authentication - specifically the header_pat branch that trusts caller-supplied X-Atlassian-Jira-Url or X-Atlassian-Confluence-Url headers; deployments not using header-based auth are unaffected. No user credentials or interaction are needed (PR:N/UI:N), but exploitation is race-dependent: the attacker must control a DNS name with a short TTL that returns a public/global IP during validate_url_for_ssrf and rebinds to an internal/metadata IP (127.0.0.1, 169.254.169.254) before the HTTP client re-resolves and connects. Success is probabilistic (advisory cites ~50% per attempt), and value is highest where a cloud metadata endpoint or internal services are reachable from the server.

The published CVSS 3.1 vector (AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N = 7.5) rates this as a network-reachable, unauthenticated, low-complexity SSRF with high confidentiality impact - a genuinely serious profile on paper. However, the vendor GHSA advisory explicitly argues for AC:H, noting DNS rebinding is probabilistic and requires multiple attempts (the PoC estimates ~50% success per try), so the AC:L in the NVD vector overstates ease of exploitation; treat AC as High. EPSS is low at 0.42% (36th percentile) and the CVE is NOT on CISA KEV, both consistent with no evidence of mass, automated exploitation. A public exploit path exists (documented rbndr.us technique in the advisory), so exploitation is feasible and reproducible, but publicly available exploit code is a distinct and lesser signal than confirmed active exploitation. Net: this is a credible, patch-worthy SSRF that can reach cloud metadata (169.254.169.254) and steal IAM credentials, but real-world risk is bounded - it only affects deployments that accept header-based PAT authentication (the header_pat branch), and successful exploitation is race-dependent. Prioritize for environments running MCP Atlassian with header-based auth exposed to untrusted callers; deprioritize where that branch is not enabled.

An unauthenticated attacker sends a request to an exposed MCP Atlassian server with X-Atlassian-Jira-Url (or X-Atlassian-Confluence-Url) pointing at a DNS-rebinding hostname (e.g. via rbndr.us) plus any X-Atlassian-Jira-Personal-Token value. The hostname resolves to a public IP during validate_url_for_ssrf validation, then rebinds to 169.254.169.254 by the time the HTTP client connects, causing the server to fetch cloud metadata and expose IAM credentials. A public PoC using the rbndr.us rebinding service is documented in the advisory, succeeding with roughly 50% probability per attempt.