Summary
MCP Atlassian: SSRF redirect protection missing for basic-auth and OAuth authentication branches
_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:
- Attacker controls or compromises an Atlassian instance (Cloud or Server)
- MCP server connects using basic auth or OAuth credentials (most production setups)
- Atlassian returns
302 Location: http://169.254.169.254/latest/meta-data/iam/security-credentials/ - The unprotected session follows the redirect
- 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.
from unittest.mock import MagicMock
import requests
from mcp_atlassian.servers.dependencies import _make_ssrf_safe_hook
from mcp_atlassian.utils.urls import validate_url_for_ssrf
from mcp_atlassian.jira import JiraFetcher
from mcp_atlassian.jira.config import JiraConfig
config = JiraConfig(
url="https://attacker.atlassian.net",
auth_type="basic",
username="[email protected]",
api_token="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")
fake_redirect = MagicMock(spec=requests.Response)
fake_redirect.is_redirect = True
fake_redirect.headers = {"Location": "http://169.254.169.254/latest/meta-data/"}
blocked = False
for h in hooks:
try:
h(fake_redirect)
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 = _make_ssrf_safe_hook(validate_url_for_ssrf)
try:
hook(fake_redirect)
except ValueError as e:
print("header-PAT branch blocks:", e)
Output:
$ 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 attach_ssrf_hook=True to _create_and_validate() in branches 2 and 3, the same way branch 1 already does.
Untrusted input controls the target URL of a server-initiated request, which may reach internal services not otherwise accessible from outside. Typical impact: access to internal metadata services, internal APIs, or cloud credentials.
CVE-2026-77261 has a CVSS score of 7.1 (High). The vector is network-reachable, low privileges required, and no user interaction. A CVSS score reflects the worst-case severity of the vulnerability, not your specific exposure. Whether this affects your application depends on whether the vulnerable code is present and reachable in your environment. A fixed version is available (0.22.0); upgrading removes the vulnerable code path.
Affected versions
Security releases
Kodem intelligence
Severity tells you how bad this could be in the worst case. It does not tell you whether you are exposed. Exploitability and impact are functions of runtime truth: whether the vulnerable code is present, reachable, and actually executes in your application. A vulnerable package can sit in your dependency tree and never run.
Kodem, an Intelligent Application Security platform, uses runtime intelligence to reveal which vulnerabilities actually execute in production, so teams prioritize the ones that genuinely matter. Kodem's runtime-powered SCA identifies whether this CVE is reachable in your applications.
Already deployed Kodem?
See it in your environmentNew to Kodem? Get a demo →Remediation advice
Kodem Kai can prioritize this vulnerability in your dependency tree and generate a fix recommendation.
Frequently Asked Questions
- What is CVE-2026-77261? CVE-2026-77261 is a high-severity server-side request forgery (SSRF) vulnerability in mcp-atlassian (pip), affecting versions < 0.22.0. It is fixed in 0.22.0. Untrusted input controls the target URL of a server-initiated request, which may reach internal services not otherwise accessible from outside.
- How severe is CVE-2026-77261? CVE-2026-77261 has a CVSS score of 7.1 (High). This score reflects the worst-case severity of the vulnerability, not your specific exposure. Whether it represents real risk in your environment depends on whether the vulnerable code is present and reachable.
- Which versions of mcp-atlassian are affected by CVE-2026-77261? mcp-atlassian (pip) versions < 0.22.0 is affected.
- Is there a fix for CVE-2026-77261? Yes. CVE-2026-77261 is fixed in 0.22.0. Upgrade to this version or later.
- Is CVE-2026-77261 exploitable, and should I be worried? Whether CVE-2026-77261 is exploitable in your environment depends on whether the vulnerable code is present and reachable. A CVSS score is a worst-case rating; it does not account for your specific deployment, configuration, or usage patterns. Kodem, an Intelligent Application Security platform, uses runtime intelligence to show which vulnerabilities actually execute in production, so you can focus on the ones that represent real risk. Get a demo
- What actually determines whether CVE-2026-77261 is exploitable, and how bad it is? Exploitability and impact are not fixed properties of a CVE. They depend on runtime truth: whether the vulnerable code is present, reachable, and actually executes in your application. A high CVSS score on a dependency that never runs is not the same as real risk. Kodem, an Intelligent Application Security platform, uses runtime intelligence to reveal which vulnerabilities actually execute in production, so teams prioritize the ones that genuinely matter.
- How do I fix CVE-2026-77261? Upgrade
mcp-atlassianto 0.22.0 or later.