MCP Atlassian: SSRF redirect protection missing for basic-auth and OAuth authentication branches

Summary

_make_ssrf_safe_hook() 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/mcp_atlassian/servers/dependencies.py, three branches construct a fetcher and call _create_and_validate(). Only Branch 1 passes attach_ssrf_hook=True:

# Branch 1 (header PAT) — hook attached
return _create_and_validate(request, spec, header_config, "header_pat",
                             attach_ssrf_hook=True)

# Branch 2 (basic auth) — hook missing
return _create_and_validate(request, spec, user_config, "basic",
                             user_email=user_email)

# Branch 3 (OAuth/PAT) — hook missing
return _create_and_validate(request, spec, user_config, "oauth_pat",
                             user_email=user_email)

attach_ssrf_hook defaults to False, so branches 2 and 3 silently skip the protection. The hook itself (_make_ssrf_safe_hook) is straightforward — it checks response.is_redirect, grabs the Location header, and calls validate_url_for_ssrf() 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)

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