CVE-2026-27826: MCP Atlassian Header SSRF

CVE-2026-27826's original header-based SSRF was fixed in 0.17.0. Separate follow-up SSRF flaws were fixed in 0.22.0; check each advisory before setting a fleet minimum.^{[1], [2], [6], [8], [9], [10], [11]}

💡 Plain English Explainer (ELI5)

Imagine a mailroom that is allowed to deliver packages only to a company’s approved offices. A visitor writes a different destination on a special form, and the mailroom follows it without checking. The server-side fetcher is the mailroom: the request headers supplied a destination, and the server made the outbound request. The 0.17.0 fix checks the submitted URL before the server connects and checks any redirect destination too; an operator may additionally configure an allowed-domain list.^{[1], [2]}

Core Concepts & Subsystem Terms

Server-side request forgery (SSRF): A flaw that lets a caller influence a server's outbound request so it reaches a destination the application did not intend to contact.^{[1], [4]}
MCP transport: The communication channel between an MCP client and server. This issue affected the streamable-HTTP and SSE transports, not the default stdio-only deployment described by the advisory.^[1]
Header-based tenant authentication: A multi-tenant mode that accepts per-request Atlassian URL and token headers to construct a tenant-specific API client.^{[1], [2]}
Egress policy: Network controls that restrict which destinations a service can contact, limiting the impact of application-level URL validation failures.^{[12], [1]}
Indirect prompt injection: Untrusted content returned by a tool can contain instructions that influence a model. In this CVE, the advisory describes attacker-controlled service responses entering tool results; this is a separate impact path from SSRF itself.^{[1], [7]}
Separate SSRF follow-up fixes: The original CVE-2026-27826 advisory lists 0.17.0 as fixed. The maintainer later documented four distinct incomplete-fix paths as CVE-2026-77242, CVE-2026-77267, CVE-2026-77249, and CVE-2026-77274; each advisory lists 0.22.0 as patched. These are separate CVEs, not a broadened affected range for CVE-2026-27826. Review any later advisories before choosing a fleet-wide minimum.^{[8], [9], [10], [11]}

Framework mappings

CWE reference for the weakness described in this guide: CWE-918
OWASP GenAI 2025 — LLM01:2025 Prompt Injection
D3-OTF Outbound Traffic Filtering — This guide's outbound network restriction limits which destinations the service or host can reach.

Root Cause Analysis

In the affected HTTP middleware path, the server extracted X-Atlassian-Jira-Url or X-Atlassian-Confluence-Url from a request and passed the value into a JiraConfig or ConfluenceConfig used to construct a fetcher. For the vulnerable header-based authentication branch, the destination was not checked against the server's configured tenant URL or a destination policy before the fetcher made its initial API request. The maintainer advisory identifies the request middleware and dependency-provider path, rather than an individual MCP tool handler. The issue requires the affected HTTP transport and header-based authentication conditions; do not generalize it to every MCP deployment.^{[1], [2]}

Step-by-Step Attack Flow

Step 1

Reachable HTTP transport

The deployment uses the streamable-HTTP or SSE transport and exposes the MCP endpoint to a caller who can reach it.^{[1], [2]}

Step 2

Request headers select a service URL

In the affected header-based authentication path, Jira or Confluence URL and token headers are present without the Authorization header expected by the alternate path.^{[1], [2]}

Step 3

Middleware constructs the fetcher

The middleware stores the URL from the request, and the dependency provider uses it to configure an Atlassian fetcher without enforcing the intended destination boundary.^{[1], [2]}

Step 4

The server makes an outbound request

Fetcher initialization makes a request to the caller-selected destination. Depending on network reachability and the destination response, this can expose internal services or feed attacker-controlled content into tool results.^{[1], [2]}

Source Code: Flaw vs. Secure Implementation

The vulnerable excerpt lets a request-header URL select the server's outbound destination. The upstream 0.17.0 patch does not replace that header-based tenant mode with a server-side tenant registry: it validates the supplied Jira or Confluence URL in ASGI middleware before fetcher creation, then adds a response hook to validate redirect destinations. The hardened excerpt shows those two upstream controls; it omits the validator implementation. A server-side tenant registry is a stronger alternative architecture, not what this patch implements. The later 0.22.0 advisories document separate residual paths, so do not treat 0.17.0 as the fleet-wide minimum without reviewing them. DNS validation also must be enforced at connection time to resist rebinding; a one-time hostname lookup is not a complete SSRF boundary.^{[1], [2]}

Source excerpt: Upstream middleware and fetcher patch excerpt (Jira path; Confluence has the equivalent guard).

UNPATCHED FLAW

header_jira_fetcher = JiraFetcher(config=header_config)
current_user_id = header_jira_fetcher.get_current_user_account_id()

HARDENED SECURE PATCH

ssrf_error = validate_url_for_ssrf(jira_url_str)
if ssrf_error:
    scope["state"]["auth_validation_error"] = (
        f"Forbidden: Invalid Jira URL - {ssrf_error}"
    )
    return

header_jira_fetcher = JiraFetcher(config=header_config)
header_jira_fetcher.jira._session.hooks["response"].append(
    _make_ssrf_safe_hook(validate_url_for_ssrf)
)
current_user_id = header_jira_fetcher.get_current_user_account_id()

Engineering & System Hardening Checklist

✓Do not accept tenant base URLs from unauthenticated or caller-controlled headers; resolve the tenant from authenticated identity and server-side configuration.^{[1], [2]}
✓Allow only explicitly provisioned HTTPS Atlassian hostnames for each tenant; reject userinfo, unexpected ports, and ambiguous URL forms.^{[1], [8], [9], [10], [11]}
✓Apply the destination policy to redirects and to the actual connection target, not only to the initial parsed URL.^{[2], [8]}
✓Restrict outbound network access from MCP services so loopback, private, link-local, and metadata destinations are unreachable unless explicitly required.^{[12], [1]}
✓Treat all tool results as untrusted content; do not let retrieved Jira or Confluence text expand tool permissions or authorize actions.^{[1], [7]}
✓Audit every code path that constructs a JiraFetcher or ConfluenceFetcher, including helper calls that may use a separate HTTP session.^{[2], [8], [9], [10], [11]}
✓Upgrade past 0.17.0 to address this CVE, then review current maintainer advisories for later, separately tracked SSRF findings before setting a fleet-wide minimum version.^{[1], [6], [8], [9], [10], [11]}
✓Keep the version decisions separate: 0.17.0 fixes the original CVE-2026-27826 path; the four later SSRF advisories (CVE-2026-77242, CVE-2026-77267, CVE-2026-77249, CVE-2026-77274) list 0.22.0 as patched. Check the current advisory list for newer findings before setting a fleet-wide minimum.^{[6], [8], [9], [10], [11]}