GHSA-6529-c226-h328: SSRF

Summary

makessrfsafehook() blocks HTTP redirects to private/internal IPs by validating the Location header before the client follows a 3xx response. The problem is that this hook is only attached in one of three authentication branches — the header-PAT path. Basic auth and OAuth branches skip it entirely, so if the connected Atlassian server returns a redirect to something like http://169.254.169.254/, the requests session follows it without complaint.

This is an incomplete fix for GHSA-7r34-79r5-rcc9. The hook works fine when it's there — it just isn't there for most production auth configurations.

Details

In src/mcpatlassian/servers/dependencies.py, three branches construct a fetcher and call createandvalidate(). Only Branch 1 passes attachssrfhook=True:

python Branch 1 (header PAT) — hook attached return createandvalidate(request, spec, headerconfig, "headerpat", attachssrfhook=True)

Branch 2 (basic auth) — hook missing return createandvalidate(request, spec, userconfig, "basic", useremail=useremail)

Branch 3 (OAuth/PAT) — hook missing return createandvalidate(request, spec, userconfig, "oauthpat", useremail=useremail)

attachssrfhook defaults to False, so branches 2 and 3 silently skip the protection. The hook itself (makessrfsafehook) is straightforward — it checks response.isredirect, grabs the Location header, and calls validateurlforssrf() to reject private IPs. It works correctly when present.

Typical attack flow:

1. Attacker controls or compromises an Atlassian instance (Cloud or Server) 2. MCP server connects using basic auth or OAuth credentials (most production setups) 3. Atlassian returns 302 Location: http://169.254.169.254/latest/meta-data/iam/security-credentials/ 4. The unprotected session follows the redirect 5. AWS IAM credentials (or other internal service data) are returned to the attacker

PoC

Tested on commit d8bc786 (v0.21.1). No real credentials needed.

python from unittest.mock import MagicMock import requests

from mcpatlassian.servers.dependencies import makessrfsafehook from mcpatlassian.utils.urls import validateurlforssrf from mcpatlassian.jira import JiraFetcher from mcpatlassian.jira.config import JiraConfig

config = JiraConfig( url="https://attacker.atlassian.net", authtype="basic", username="victim@example.com", apitoken="victim-token", ) fetcher = JiraFetcher(config=config) session = fetcher.jira.session

hooks = session.hooks.get("response", []) print("hooks on basic-auth session:", [h.name for h in hooks] or "none")

fakeredirect = MagicMock(spec=requests.Response) fakeredirect.isredirect = True fakeredirect.headers = {"Location": "http://169.254.169.254/latest/meta-data/"}

blocked = False for h in hooks: try: h(fakeredirect) except ValueError as e: blocked = True print("blocked:", e)

if not blocked: print("redirect to 169.254.169.254 not blocked on basic-auth session")

show header-PAT branch does block it hook = makessrfsafehook(validateurlforssrf) try: hook(fakeredirect) except ValueError as e: print("header-PAT branch blocks:", e)

Output:

<img width="2490" height="214" alt="image" src="https://github.com/user-attachments/assets/c7d9d7e2-4c37-4abd-95a3-4ddd9f6bd735" />

$ uv run python3 /tmp/test.py hooks on basic-auth session: none redirect to 169.254.169.254 not blocked on basic-auth session header-PAT branch blocks: Redirect blocked (SSRF): Blocked IP address: 169.254.169.254 (non-global)

Impact

Basic auth and OAuth cover most production Atlassian Cloud deployments, so this affects the majority of HTTP-mode multi-user setups. An attacker with control over the Atlassian server can redirect MCP server requests to internal infrastructure — cloud metadata endpoints, internal Kubernetes API, databases, or any service reachable from the MCP server's network.

The fix is one line per affected branch: pass attachssrfhook=True to createandvalidate() in branches 2 and 3, the same way branch 1 already does.