Atlassian MCP server still open to SSRF after partial fix

The popular mcp-atlassian package, which lets AI agents talk to Jira and Confluence through the Model Context Protocol, contains an incompletely fixed server-side request forgery flaw, according to a GitHub security advisory published on 22 September 2026. The advisory, tracked as GHSA-5wf4-jqxh-8gm3 and CVE-2026-77267, affects the PyPI package maintained by the developer sooperset. All versions before fix commit 5cd697dfce91 are listed as affected.

Server-side request forgery, or SSRF, is a flaw where an attacker persuades a server to make HTTP requests to a destination of the attacker's choosing. In this case, the advisory says the package's UserTokenMiddleware reads URLs from two HTTP headers, X-Atlassian-Jira-Url and X-Atlassian-Confluence-Url, and hands them straight to the API client constructors with no validation at all.

The advisory sets out where the problem sits in the code. In main.py, the function _process_authentication_headers() pulls URLs out of the ASGI headers without checking them. In dependencies.py, get_jira_fetcher() then builds a JiraConfig object using the header value as the url field. According to the advisory there is no validate_url call, no IP range check and no hostname validation anywhere in that path.

Crucially, the advisory describes the existing remediation as incomplete. A fix added URL validation to some code paths, but the header-based extraction in _process_authentication_headers() still passes raw URLs through. The configuration objects derived from those headers use the header URL directly, and the fetcher goes on to make HTTP requests to it.

The practical impact described in the advisory is straightforward. An attacker who can send headers to the server can set X-Atlassian-Jira-Url to http://169.254.169.254/latest/meta-data/, the cloud instance metadata address used by AWS, and reach that endpoint through the server. Any other internal service reachable from the host can be targeted the same way. The advisory notes that the server makes authenticated HTTP requests to the attacker-specified URL, meaning credentials intended for Atlassian may be sent to the chosen destination.

The advisory includes a short proof of concept. It shows the middleware decoding the x-atlassian-jira-url header with latin-1 and writing the value into the service headers dictionary unchecked. Reproduction steps published with the advisory involve cloning the repository, checking out the commit immediately before the fix commit, installing the package in editable mode and running a supplied script. The expected output is a message reading "VULNERABILITY CONFIRMED", stating that user-supplied URLs from HTTP headers are passed directly to JiraConfig and JiraFetcher with no SSRF validation.

For remediation, the advisory suggests validating all user-supplied URLs against an allowlist of permitted hostnames, or rejecting private, loopback and link-local IP ranges. It also suggests a stronger option: requiring that allowed Atlassian instance URLs be configured on the server side, rather than accepted from request headers at all.

The pattern is a familiar one for MCP servers, which often act as a bridge between a language model and an internal network. Where a deployment accepts per-request configuration from headers, the header effectively becomes an untrusted input that steers outbound traffic. Operators running mcp-atlassian in a network with reachable internal services or a cloud metadata endpoint should check which commit they are running against the patched version listed in the advisory.