Executive brief
The Atlassian MCP (Model Context Protocol) integration for Jira contains an incomplete fix for a previous SSRF vulnerability. When deployed in HTTP multi-tenant mode without server-side credentials, an attacker can manipulate a Jira URL header to point to a server under their control, then have that server redirect internal requests to arbitrary internal hosts and ports. This allows blind server-side request forgery that could discover internal services, trigger internal endpoints, or access cloud metadata endpoints—a weaker variant of the original vulnerability but still exploitable in the latest version.
Technical details
This is a residual server-side request forgery (SSRF) in the _lookup_user_by_permissions method of src/mcp_atlassian/jira/users.py. The root cause is that a single outbound HTTP request uses the module-level requests.get() instead of the SSRF-hooked session (self.jira._session.get()) that was introduced to fix CVE-2026-27826. An attacker in HTTP multi-tenant mode can set the X-Atlassian-Jira-Url header to an attacker-controlled public server (which passes the validate_url_for_ssrf() check), then have that server return an HTTP 302 redirect to an internal address. Since the bare requests.get() call follows redirects by default without the SSRF validation hook, the server issues an unauthenticated GET to the internal target. The vulnerability is gated on multi-tenant HTTP transport mode with per-request header authentication and no server-side credentials; the response body is not leaked except in narrow cases, making this blind SSRF with reduced impact compared to the original CVE.
Affected products
- Atlassian MCP v0.21.1 and possibly earlier
Timeline
- 2026-09-22: disclosed: Advisory GHSA-v9m3-wfh8-5646 published