CVE-2026-77267

### 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 ```python 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.

### 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 ```python 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.