mcp-atlassian has an incomplete SSRF remediationGHSA-5wf4-jqxh-8gm3
Fix: sooperset/mcp-atlassian#1448GHSA-5wf4-jqxh-8gm3 is a Server-Side Request Forgery (SSRF) vulnerability in mcp-atlassian. A fix is available for mcp-atlassian — see the affected versions and patch details below.
Exploitation Status
Proof-of-concept exploit code exists
- CISA’s SSVC triage found public proof-of-concept exploit code for this CVE, though no confirmed active exploitation.
Exploitation and automatability from CISA’s SSVC triage for GHSA-5wf4-jqxh-8gm3.
EPSS Exploitation Probability
Probability of exploitation in the next 30 days, from FIRST.org EPSS.
Real-World Exposure
mcp-atlassianReal-time download stats are indexed for npm and PyPI packages. This vulnerability affects PyPI packages — download data is not available via public APIs for these ecosystems.
Description
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:
git clone https://github.com/sooperset/mcp-atlassian /tmp/mcp-atlassian_testcd /tmp/mcp-atlassian_test && git checkout 5cd697dfce91~1pip install -e .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.
Affected Packages
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| 🐍PyPI | mcp-atlassian | all versions | 0.22.0pip install --upgrade 'mcp-atlassian==0.22.0' |
Affected Products
mcp atlassianmcp-atlassianDetection & mitigation playbook
Open-source dependencyDetect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for mcp-atlassian, including transitive dependencies — a direct dependency you never call can still pull in a vulnerable version.
Fix
Update mcp-atlassian to 0.22.0 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-5wf4-jqxh-8gm3 is resolved across your whole dependency graph.
Workarounds
Restrict outbound requests from the affected component to an allowlist of hosts, block access to link-local and internal address ranges at the network layer, and require authentication on internal services so a forged request cannot reach them unauthenticated.
Frequently Asked Questions
Is GHSA-5wf4-jqxh-8gm3 in your dependencies?
Find it across PyPI, including transitive dependencies.