MCP Atlassian EUVD-2026-84631

Requires MCP Atlassian < 0.22.0 configured through the basic-auth or oauth_pat authentication branch (the header-PAT branch is NOT affected because it alone attaches _make_ssrf_safe_hook / attach_ssrf_hook=True). The attacker must control or have already compromised the specific Atlassian instance the server is configured to connect to, and that instance must return a 3xx redirect whose Location points at an internal/private address (e.g. the 169.254.169.254 cloud metadata service). Exploitation further depends on an actually reachable internal target (cloud metadata endpoint or other internal service) from the MCP host. Limiting factors: not exploitable against a trusted/uncompromised Atlassian backend, not applicable to header-PAT deployments, and no end-user interaction is needed but operator-level trust in a malicious upstream is effectively a prerequisite.

This is a genuine but conditionally-gated SSRF (CWE-918). CVSS 3.1 (8.5, AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:L/A:N) reflects a network-reachable, scope-changing information-disclosure flaw, and the S:C/C:H combination is what pushes it to High - the SSRF pivots from the MCP process into internal services (e.g. the 169.254.169.254 cloud metadata endpoint) to steal IAM credentials. However, the exploitation-signal cluster points to LOW real-world urgency: EPSS is only 0.32% (26th percentile), and SSVC records Exploitation=none, Automatable=no, Technical Impact=partial - i.e. no observed exploitation and not mass-automatable. A public PoC exists (author-supplied in the GHSA advisory, tested on v0.21.1/commit d8bc786), so exploit knowledge is public, but PoC availability is NOT active exploitation and this is not on CISA KEV. The most important nuance the raw CVSS understates: the attacker must CONTROL OR HAVE COMPROMISED the Atlassian instance the MCP server is already configured to trust - this is not drive-by exploitation of a default deployment, but abuse of a malicious/compromised upstream that the operator deliberately points at. That precondition (plus a reachable internal metadata/service endpoint) materially raises real attack complexity beyond the AC:L in the NVD vector. Net: a real defect worth patching, but a targeted/scenario-dependent issue rather than a wormable priority.

An MCP Atlassian server (< 0.22.0) is configured with basic-auth or OAuth/PAT credentials pointing at an Atlassian instance the attacker controls or has compromised. When the MCP server makes a request, that instance replies with a 302 redirect to http://169.254.169.254/latest/meta-data/iam/security-credentials/; because the SSRF redirect hook is only attached in the header-PAT branch, the unprotected session follows the redirect and returns cloud metadata (e.g. AWS IAM credentials) to the attacker. A working PoC is published in the GHSA advisory (tested on v0.21.1), though no active exploitation has been reported.