CVE-2026-27826: SSRF in MCP Atlassian

Der ursprüngliche, headerbasierte SSRF-Fehler CVE-2026-27826 wurde in 0.17.0 behoben. Separate spätere SSRF-Schwachstellen wurden in 0.22.0 behoben; prüfen Sie jede Meldung, bevor Sie eine Mindestversion für die Flotte festlegen.^{[1], [2], [6], [8], [9], [10], [11]}

💡 Einfache Erklärung (ELI5)

Stell dir eine Poststelle vor, die Pakete nur an freigegebene Firmenstandorte liefern darf. Ein Besucher trägt auf einem Sonderformular ein anderes Ziel ein, und die Poststelle übernimmt es ungeprüft. Der serverseitige Fetcher ist diese Poststelle: Die Anfrage-Header bestimmten das Ziel, und der Server führte den ausgehenden Abruf aus. Die Korrektur in 0.17.0 prüft die übermittelte URL vor dem Verbindungsaufbau und kontrolliert auch Weiterleitungen; Betreiber können zusätzlich eine Domain-Allowlist konfigurieren.^{[1], [2]}

Kernkonzepte & Begriffe

Server-side request forgery (SSRF): Ein Fehler, durch den ein Aufrufer eine ausgehende Serveranfrage so beeinflussen kann, dass sie ein von der Anwendung nicht vorgesehenes Ziel erreicht.^{[1], [4]}
MCP-Transport: Kommunikationskanal zwischen einem MCP-Client und -Server. Betroffen waren hier streamable-HTTP und SSE, nicht die im Advisory beschriebene Bereitstellung ausschließlich über stdio.^[1]
Headerbasierte Mandantenauthentifizierung: Ein Mehrmandantenmodus, der pro Anfrage Atlassian-URLs und -Tokens annimmt, um einen mandantenspezifischen API-Client zu erstellen.^{[1], [2]}
Egress-Richtlinie: Netzwerkkontrollen, die Ziele einschränken, die ein Dienst kontaktieren darf, und so die Auswirkungen fehlerhafter URL-Prüfungen in der Anwendung begrenzen.^{[12], [1]}
Indirekte Prompt-Injection: Nicht vertrauenswürdige Inhalte aus einem Tool können Anweisungen enthalten, die ein Modell beeinflussen. Für dieses CVE beschreibt das Advisory, dass angreiferkontrollierte Antworten in Tool-Ergebnisse gelangen; dies ist eine andere Auswirkung als SSRF selbst.^{[1], [7]}
Spätere SSRF-Korrekturen: Die ursprüngliche CVE-2026-27826-Meldung nennt 0.17.0 als behobene Version. Der Maintainer dokumentierte später vier separate unvollständige Korrekturpfade als CVE-2026-77242, CVE-2026-77267, CVE-2026-77249 und CVE-2026-77274; jede Meldung nennt 0.22.0 als behobene Version. Das sind eigene CVEs und keine Erweiterung des betroffenen Bereichs von CVE-2026-27826. Prüfen Sie spätere Meldungen, bevor Sie eine Mindestversion für die gesamte Flotte festlegen.^{[8], [9], [10], [11]}

Framework-Zuordnungen

CWE-Referenz für die in diesem Leitfaden beschriebene Schwachstelle: CWE-918
OWASP GenAI 2025 — LLM01:2025 Prompt-Injection
D3-OTF Filterung des ausgehenden Datenverkehrs — Die in diesem Leitfaden beschriebene Beschränkung des ausgehenden Netzwerkverkehrs begrenzt die für den Dienst oder Host erreichbaren Ziele.

Ursachenanalyse

Im betroffenen HTTP-Pfad las der Server X-Atlassian-Jira-Url oder X-Atlassian-Confluence-Url aus der Anfrage und übergab den Wert an eine JiraConfig oder ConfluenceConfig, aus der ein Fetcher erstellt wurde. Im verwundbaren Zweig der headerbasierten Authentifizierung wurde das Ziel vor der ersten Fetcher-Anfrage weder mit der serverseitig konfigurierten Mandanten-URL noch mit einer Zielrichtlinie abgeglichen. Das Advisory des Maintainers nennt die Request-Middleware und den Dependency-Provider, nicht einen einzelnen MCP-Tool-Handler. Der Fehler setzt den betroffenen HTTP-Transport und die Bedingungen des Header-Authentifizierungspfads voraus; er gilt nicht pauschal für jede MCP-Bereitstellung.^{[1], [2]}

Schritt-für-Schritt Angriffsablauf

Schritt 1

Erreichbarer HTTP-Transport

Die Bereitstellung nutzt streamable-HTTP oder SSE und macht den MCP-Endpunkt für einen erreichbaren Aufrufer zugänglich.^{[1], [2]}

Schritt 2

Header wählen die Dienst-URL

Im betroffenen Header-Authentifizierungspfad sind Jira- oder Confluence-URL und -Token vorhanden, während der vom alternativen Pfad erwartete Authorization-Header fehlt.^{[1], [2]}

Schritt 3

Die Middleware erstellt den Fetcher

Die Middleware speichert die empfangene URL; der Dependency-Provider verwendet sie zur Konfiguration eines Atlassian-Fetchers, ohne die vorgesehene Zielgrenze durchzusetzen.^{[1], [2]}

Schritt 4

Der Server sendet eine ausgehende Anfrage

Beim Initialisieren des Fetchers wird eine Anfrage an das vom Aufrufer bestimmte Ziel gesendet. Je nach Netz und Antwort können interne Dienste offengelegt oder fremdkontrollierte Inhalte in Tool-Ergebnisse übernommen werden.^{[1], [2]}

Quellcode: Verwundbar vs. Sicher

Der verwundbare Ausschnitt lässt eine URL aus einem Request-Header das ausgehende Ziel des Servers bestimmen. Der Upstream-Patch 0.17.0 ersetzt diesen headerbasierten Mandantenmodus nicht durch ein serverseitiges Mandantenverzeichnis: Er validiert die übergebene Jira- oder Confluence-URL in der ASGI-Middleware vor der Fetcher-Erstellung und ergänzt danach einen Response-Hook zur Prüfung von Redirect-Zielen. Der gehärtete Ausschnitt zeigt diese beiden Upstream-Kontrollen; die Validator-Implementierung ist ausgelassen. Ein serverseitiges Mandantenverzeichnis ist eine stärkere alternative Architektur, aber nicht Bestandteil dieses Patches. Die späteren Advisories zu 0.22.0 dokumentieren separate verbliebene Pfade; setzen Sie daher 0.17.0 nicht ohne Prüfung als Mindestversion für die gesamte Flotte an. Die DNS-Prüfung muss außerdem beim Verbindungsaufbau greifen, um Rebinding abzuwehren; eine einmalige Namensauflösung schließt die SSRF-Grenze nicht vollständig.^{[1], [2]}

Quelltextauszug: Auszug aus dem Upstream-Patch für Middleware und Fetcher (Jira-Pfad; Confluence hat dieselbe Schutzprüfung).

VERWUNDBARE IMPLEMENTIERUNG

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

GEHÄRTETER SICHERHEITS-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()

Checkliste für Engineering & Systemsicherheit

✓Übernimm Mandanten-Basis-URLs nicht aus unauthentifizierten oder vom Aufrufer kontrollierten Headern; ermittle den Mandanten über authentifizierte Identität und Serverkonfiguration.^{[1], [2]}
✓Erlaube je Mandant nur ausdrücklich eingerichtete HTTPS-Atlassian-Hostnamen; lehne Userinfo, unerwartete Ports und mehrdeutige URL-Formen ab.^{[1], [8], [9], [10], [11]}
✓Wende die Zielrichtlinie auf Weiterleitungen und das tatsächliche Verbindungsziel an, nicht nur auf die zunächst geparste URL.^{[2], [8]}
✓Beschränke ausgehenden Netzwerkverkehr der MCP-Dienste, damit Loopback-, private, Link-Local- und Metadatenziele standardmäßig nicht erreichbar sind.^{[12], [1]}
✓Behandle alle Tool-Ergebnisse als nicht vertrauenswürdige Inhalte; aus Jira oder Confluence abgerufener Text darf Berechtigungen weder erweitern noch Aktionen autorisieren.^{[1], [7]}
✓Prüfe jeden Pfad, der JiraFetcher oder ConfluenceFetcher erstellt, einschließlich Hilfsfunktionen mit möglicherweise separater HTTP-Sitzung.^{[2], [8], [9], [10], [11]}
✓Aktualisiere für dieses CVE auf eine Version nach 0.17.0 und prüfe anschließend aktuelle Maintainer-Advisories zu separat erfassten SSRF-Befunden, bevor du eine Mindestversion für alle Systeme festlegst.^{[1], [6], [8], [9], [10], [11]}
✓Halten Sie die Versionsentscheidungen getrennt: 0.17.0 behebt den ursprünglichen Pfad von CVE-2026-27826; die vier späteren SSRF-Meldungen (CVE-2026-77242, CVE-2026-77267, CVE-2026-77249 und CVE-2026-77274) nennen 0.22.0 als behoben. Prüfen Sie neuere Meldungen, bevor Sie eine Mindestversion für die Flotte festlegen.^{[6], [8], [9], [10], [11]}