MCP Atlassian CVE-2026-77249

Exploitation requires an MCP caller able to control the public Jira base URL the server uses, and a Jira user-lookup operation that routes through JiraUserMixin._lookup_user_by_permissions (the code path that calls the unhooked module-level requests.get rather than the SSRF-protected session). The attacker must also run or control a server at that URL that returns a redirect to an internal address. Practical impact is limited: the SSRF is blind/low-confidentiality (C:L, no I/A), and the attacker-controlled-URL requirement means this is most exploitable in HTTP/multi-user or shared-credential deployments where a caller can supply their own Jira endpoint; single-user stdio deployments with a fixed trusted Jira URL are not realistically exposed. Fixed in v0.22.0, which routes the call through the hooked session, adds make_ssrf_redirect_hook, and mounts DNS-rebind pinning.

This is a genuine but low-severity SSRF (CWE-918). The vendor CVSS of 5.3 (AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N) is defensible: the flaw only yields limited confidentiality impact (C:L) via a blind/probe SSRF, with no integrity or availability impact. No EPSS score, no CISA KEV listing, and no public exploit code were provided, so this is 'no public exploit identified at time of analysis.' There is no SSVC data supplied. The most important caveat is the PR:N rating: exploitation requires a caller who can control the public Jira URL that the MCP server contacts, which in practice means a permitted MCP caller in an HTTP/multi-user deployment - arguably PR:L rather than PR:N, which would lower the score to roughly 4.3. Signals are internally consistent (moderate CVSS, no exploitation evidence, niche product), so this is a routine-priority patch item rather than an urgent one; the real value of the fix is that it closes a bypass of an earlier SSRF hardening (CVE-2026-27826) rather than a novel high-impact bug.

An attacker who can act as an MCP caller supplies a public Jira base URL under their control; when JiraUserMixin._lookup_user_by_permissions issues a user-lookup via the unhooked module-level requests.get, the attacker's server responds with an HTTP redirect pointing at an internal address (e.g., cloud metadata or an internal service). Because this call path bypasses the SSRF redirect hook added for CVE-2026-27826, the server follows the redirect and contacts the internal target on the attacker's behalf. No public exploit code was identified, and the SSRF is largely blind, yielding limited confidentiality (C:L).