GitHub Security Advisory: GHSA-7r34-79r5-rcc9
Package: mcp-atlassian (PIP)
Severity: HIGH (CVSS 8.2)
CWE: CWE-918: Server-Side Request Forgery (SSRF)
Vulnerable versions: < 0.17.0
Patched in: 0.17.0

Summary: MCP Atlassian has SSRF via unvalidated X-Atlassian-Jira-Url / X-Atlassian-Confluence-Url headers

Details:
### Summary
An unauthenticated attacker who can reach the mcp-atlassian HTTP endpoint can force the server process to make outbound HTTP requests to an arbitrary attacker-controlled URL by supplying two custom HTTP headers without an `Authorization` header. No authentication is required. The vulnerability exists in the HTTP middleware and dependency injection layer — not in any MCP tool handler - making it invisible to tool-level code analysis. In cloud deployments, this could enable theft of IAM role credentials via the instance metadata endpoint (`169.254.169.254`). In any HTTP deployment it enables internal network reconnaissance and injection of attacker-controlled content into LLM tool results.

### Details
The server supports a multi-tenant HTTP authentication mode where clients supply per-request Jira/Confluence URLs via custom headers. The middleware (`src/mcp_atlassian/servers/main.py:436–448`) extracts `X-Atlassian-Jira-Url` from the request and stores it in request state with no validation. The dependency provider (`src/mcp_atlassian/servers/dependencies.py:189–217`) then uses this value directly as the `url=` parameter when constructing a `JiraConfig` and `JiraFetcher`. The first method call on the fetcher (`get_current_user_account_id()`) immediately issues a `GET` request to `{header_url}/rest/api/2/myself` — an outbound SSRF call to the attacker-controlled URL.

No comparison is made against the server-configured `JIRA_URL` environment variable. No private IP range blocklist is applied. No URL scheme allowlist is enforced.

  **Trigger conditions — all four must hold:**
  1. Server running with `--transport streamable-http` or `--transport sse`
  2. Request contains `X-Atlassian-Jira-Url` header (any non-empty value)
  3. Request contains `X-Atlassian-Jira-Personal-Token` header (any non-empty value)
  4. Request has **no** `Authorization` header

  An identical vulnerability exists for Confluence at `dependencies.py:341–393` via `X-Atlassian-Confluence-Url` +
  `X-Atlassian-Confluence-Personal-Token`.

  **Root cause - middleware** (`src/mcp_atlassian/servers/main.py:436–448`):
  ```python
  # When service headers are present and no Authorization header is provided,
  # auth type is set to "pat" but user_atlassian_token is NOT set.
  # This is what routes execution to the vulnerable path below.
  if service_headers and (jira_token_str and jira_url_str):
      scope["state"]["user_atlassian_auth_type"] = "pat"

  Root cause - dependency provider (src/mcp_atlassian/servers/dependencies.py:189–217):
  if (
      user_auth_type == "pat"
      and jira_url_header           # attacker-controlled, no validation
      and jira_token_header
      and not hasattr(request.state, "user_atlassian_token")
  ):
      header_config = JiraConfig(
          url=jira_url_header,      # used directly, no allowlist check
          personal_token=jira_token_header,
          ...
      )
      header_jira_fetcher = JiraFetcher(config=header_config)