MCP Atlassian CVE-2026-77267

Exploitation requires that the attacker be a permitted MCP caller able to set the X-Atlassian-Jira-Url or X-Atlassian-Confluence-Url HTTP headers, which are processed by _process_authentication_headers and used to construct Atlassian fetchers without calling validate_url_for_ssrf. This is realistic in header-based/multi-tenant or shared-credential deployments (e.g., HTTP streamable transport) where clients supply these headers; it is limited by the PR:L requirement (the caller must reach the authenticated header-processing flow) and by the presence of a routable internal target (e.g., a cloud metadata service). Deployments running v0.22.0 or later, or that never expose the X-Atlassian-*-Url header path to untrusted callers, are not exploitable.

This is a genuine, well-corroborated SSRF (CWE-918) with clear source-code evidence, but its real-world priority is moderate rather than critical. The vendor CVSS 4.0 vector (8.3, AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:N/VA:N/SC:H) tells a coherent story: network-reachable, low complexity, but requiring low privileges (PR:L) - the attacker must already be a permitted MCP caller able to set the X-Atlassian-Jira-Url/X-Atlassian-Confluence-Url headers. VC:H plus SC:H reflects the SSRF pivot: high confidentiality impact reaching a subsequent internal/metadata system (e.g., cloud instance-metadata credentials), with no integrity or availability impact (VI/VA:N). No EPSS score, no CISA KEV listing, and no public POC were provided, so exploitation is not confirmed in the wild and there is no evidence of mass exploitation. The key signals are consistent (no CVSS-vs-description conflict), and the flaw is explicitly framed by the vendor as bypassing the incomplete CVE-2026-27826 remediation, which raises confidence it is a real, verified regression. Net: prioritize for anyone running mcp-atlassian in a multi-tenant/shared-credential or HTTP-transport deployment where untrusted callers can set request headers, but it is not a drop-everything internet-wide emergency given the PR:L gate and niche footprint.

In a shared or multi-tenant mcp-atlassian deployment, an authenticated but low-privileged MCP caller sends a request that sets the X-Atlassian-Jira-Url (or X-Atlassian-Confluence-Url) header to an internal address such as the cloud metadata endpoint (e.g., 169.254.169.254). The server constructs an Atlassian fetcher from that header without validate_url_for_ssrf and issues the request, returning internal responses or leaking instance credentials. No public exploit code was identified at time of analysis, but the low attack complexity and clear code path make crafting one straightforward.