NewApp Monitoring is liveSign up free
AgentbeamBeta
AI agent vulnerability · Other MCP servers and tools

CVE-2026-77267: mcp-atlassian has an incomplete SSRF remediation

highCVSS 4.0 8.3GHSA-5wf4-jqxh-8gm3

mcp-atlassian before 0.22.0 takes Jira and Confluence base URLs from the `X-Atlassian-Jira-Url` and `X-Atlassian-Confluence-Url` request headers and uses them with no SSRF validation. A caller can aim the server's authenticated requests at internal hosts or the cloud metadata service. Upgrade to 0.22.0.

Published Sep 22, 2026 · Analysis Oct 22, 2026

What an attacker can do

UserTokenMiddleware reads those two headers. In main.py, _process_authentication_headers() decodes the raw header value and copies it into the service headers. In dependencies.py, get_jira_fetcher() builds JiraConfig with url=jira_url_header as given. No validate_url call, IP range check or hostname check sits on this path.

The fetcher then sends HTTP requests to whatever the caller supplied. Setting X-Atlassian-Jira-Url to the metadata address 169.254.169.254 makes the MCP server query the AWS metadata service, and any internal host reachable from the server can be targeted the same way. The requests are authenticated, so credentials the server attaches go along.

The attacker needs network access to the MCP HTTP endpoint and the low privilege the CVSS vector assumes. This is an incomplete SSRF fix: earlier work added URL validation on some paths, but the header-based extraction still passes raw URLs. The reporter's script shows that user-supplied header URLs reach JiraConfig and JiraFetcher unvalidated at the commit before fix 5cd697dfce91.

Who is affected

mcp-atlassian below 0.22.0 when run with an HTTP transport that accepts per-request headers. The advisory text names all versions before commit 5cd697dfce91; the package data sets the fixed release at 0.22.0.

pip show mcp-atlassian

Stdio deployments do not take these headers from network callers.

mcp-atlassian

Ecosystem
PyPI
Affected
< 0.22.0
Fixed in
0.22.0
Check
pip show mcp-atlassian

How to fix it

Upgrade to 0.22.0:

pip install --upgrade mcp-atlassian==0.22.0

The reporter's remediation advice is to check user-supplied URLs against an allowlist of hostnames, reject private, loopback and link-local ranges, or set the allowed Atlassian URLs on the server side. Until you can upgrade, keep the HTTP endpoint off untrusted networks and block egress from the MCP host to metadata and internal ranges.

How to tell if you were hit

Inspect reverse proxy or access logs for requests carrying X-Atlassian-Jira-Url or X-Atlassian-Confluence-Url values that are not your Atlassian domain, such as IP literals, localhost or 169.254.169.254. On the MCP host, check egress logs for connections to link-local or RFC 1918 addresses started by the Python process. On AWS, review metadata access and use of the instance role from unfamiliar sources.

Original advisory

From the GitHub Advisory Database (CC BY 4.0).

Summary

The UserTokenMiddleware extracts URLs from X-Atlassian-Jira-Url and X-Atlassian-Confluence-Url HTTP headers and passes them directly to API client constructors without any SSRF validation.

Affected Package

  • Ecosystem: PyPI
  • Package: mcp-atlassian
  • Affected versions: all versions before fix commit 5cd697dfce91
  • Patched versions: >= commit 5cd697dfce91

Details

In main.py, _process_authentication_headers() extracts URLs from ASGI headers without validation. In dependencies.py, get_jira_fetcher() creates JiraConfig with url=jira_url_header directly. There is no validate_url call, no IP range check, no hostname validation.

The fix adds URL validation to some paths but the header-based URL extraction in _process_authentication_headers() still passes raw URLs through. The derived config objects use the header URL directly and the fetcher makes HTTP requests to that URL.

PoC

jira_url_header = headers.get(b"x-atlassian-jira-url")
jira_url_str = jira_url_header.decode("latin-1") if jira_url_header else None
service_headers["X-Atlassian-Jira-Url"] = jira_url_str

Steps to reproduce:

  1. git clone https://github.com/sooperset/mcp-atlassian /tmp/mcp-atlassian_test
  2. cd /tmp/mcp-atlassian_test && git checkout 5cd697dfce91~1
  3. pip install -e .
  4. python3 poc.py

Expected output:

VULNERABILITY CONFIRMED
User-supplied URLs from HTTP headers passed directly to JiraConfig/JiraFetcher with no SSRF validation

Impact

An attacker can set X-Atlassian-Jira-Url: http://169.254.169.254/latest/meta-data/ to access AWS instance metadata, or target any internal service. The server makes authenticated HTTP requests to the attacker-specified URL.

Suggested Remediation

Validate all user-supplied URLs against an allowlist of permitted hostnames or reject private/loopback/link-local IP ranges. Consider requiring server-side configuration of allowed Atlassian instance URLs.

Questions

Which headers are the problem?

X-Atlassian-Jira-Url and X-Atlassian-Confluence-Url. Their values become the base URL of the API client without any validation.

Can this reach cloud credentials?

The advisory gives the AWS instance metadata address 169.254.169.254 as an example target. Whether you get data back depends on your metadata settings and what the server returns.

How does it relate to the redirect SSRF advisory?

Different entry. This one is about request headers, while the redirect advisory covers missing hooks on basic and OAuth sessions. Both are fixed in 0.22.0.

Is it known to be exploited?

No source says so, and it is not in CISA's KEV catalog.

References

How this page is made: the data panel comes from the GitHub Advisory Database, CISA’s KEV catalog, the NVD and FIRST EPSS, and updates twice a day. The analysis is written by an AI model from the sources listed above and checked by automated rules before it is published. Check versions against the vendor's advisory before you act. Methodology

More Other MCP servers and tools vulnerabilities

All Other MCP servers and tools entries