CVE-2026-27826 : SSRF dans MCP Atlassian

La SSRF initiale de CVE-2026-27826, liée aux en-têtes, a été corrigée en 0.17.0. Des failles SSRF distinctes découvertes ensuite ont été corrigées en 0.22.0 ; vérifiez chaque avis avant de fixer la version minimale du parc.^{[1], [2], [6], [8], [9], [10], [11]}

💡 Explication en Langage Simple (ELI5)

Imaginez un service courrier autorisé à livrer des colis uniquement aux bureaux approuvés d'une entreprise. Un visiteur inscrit une autre destination sur un formulaire spécial et le personnel l'accepte sans vérifier. Le fetcher du serveur joue ce rôle : les en-têtes indiquaient la destination et le serveur effectuait la requête sortante. Le correctif 0.17.0 vérifie l’URL fournie avant la connexion et contrôle aussi chaque redirection ; l’opérateur peut ajouter une liste de domaines autorisés.^{[1], [2]}

Concepts Clés et Termes

Server-side request forgery (SSRF): Défaut qui permet d'influencer une requête sortante du serveur afin qu'elle atteigne une destination que l'application ne voulait pas contacter.^{[1], [4]}
Transport MCP: Canal de communication entre un client et un serveur MCP. Cette faille concernait les transports streamable-HTTP et SSE, pas le déploiement décrit dans l'avis qui utilise uniquement stdio.^[1]
Authentification multi-tenant par en-têtes: Mode qui reçoit des URL et jetons Atlassian pour chaque requête afin de construire un client d'API propre au tenant.^{[1], [2]}
Politique de sortie réseau: Contrôles qui limitent les destinations qu'un service peut contacter et réduisent l'impact d'une validation d'URL défaillante dans l'application.^{[12], [1]}
Injection indirecte de prompt: Un contenu non fiable renvoyé par un outil peut contenir des instructions influençant le modèle. Pour ce CVE, l'avis décrit des réponses contrôlées par un tiers intégrées aux résultats d'outils ; cet impact est distinct de la SSRF elle-même.^{[1], [7]}
Correctifs SSRF ultérieurs: L’avis initial de CVE-2026-27826 indique que la version 0.17.0 corrige la faille. Le mainteneur a ensuite documenté quatre chemins distincts de correction incomplète sous les références CVE-2026-77242, CVE-2026-77267, CVE-2026-77249 et CVE-2026-77274 ; chaque avis indique 0.22.0 comme version corrigée. Il s’agit de CVE distinctes, pas d’un élargissement de la plage affectée par CVE-2026-27826. Consultez les avis ultérieurs avant de définir une version minimale pour tout le parc.^{[8], [9], [10], [11]}

Correspondances de référentiels

Référence CWE pour la faiblesse décrite dans ce guide : CWE-918
OWASP GenAI 2025 — LLM01:2025 Injection de prompt
D3-OTF Filtrage du trafic sortant — La restriction du trafic sortant décrite dans ce guide limite les destinations accessibles au service ou à l’hôte.

Analyse de Cause Racine

Dans le parcours HTTP concerné, le serveur extrayait X-Atlassian-Jira-Url ou X-Atlassian-Confluence-Url de la requête et transmettait cette valeur à une JiraConfig ou ConfluenceConfig utilisée pour créer un fetcher. Dans la branche vulnérable d'authentification par en-têtes, la destination n'était vérifiée ni par rapport à l'URL du tenant configurée côté serveur ni au regard d'une politique de destination avant la première requête du fetcher. L'avis du mainteneur désigne le middleware de requête et le fournisseur de dépendances, pas un gestionnaire individuel d'outil MCP. La faille exige le transport HTTP concerné et les conditions d'authentification par en-têtes ; ne l'étendez pas à tous les déploiements MCP.^{[1], [2]}

Déroulement de l'Attaque Étape par Étape

Étape 1

Transport HTTP accessible

Le déploiement utilise le transport streamable-HTTP ou SSE et expose le point de terminaison MCP à un appelant pouvant l'atteindre.^{[1], [2]}

Étape 2

Les en-têtes choisissent l'URL du service

Dans le parcours d'authentification par en-têtes concerné, les en-têtes d'URL et de jeton Jira ou Confluence sont présents sans l'en-tête Authorization attendu par l'autre parcours.^{[1], [2]}

Étape 3

Le middleware construit le fetcher

Le middleware conserve l'URL reçue et le fournisseur de dépendances l'utilise pour configurer un fetcher Atlassian sans imposer la frontière de destination prévue.^{[1], [2]}

Étape 4

Le serveur envoie une requête sortante

L'initialisation du fetcher envoie une requête vers la destination choisie par l'appelant. Selon le réseau et la réponse, cela peut exposer des services internes ou injecter un contenu contrôlé par un tiers dans les résultats de l'outil.^{[1], [2]}

Code Source : Vulnérable vs Sécurisé

L’extrait vulnérable permet à une URL d’en-tête de choisir la destination sortante du serveur. Le correctif amont 0.17.0 ne remplace pas ce mode de tenant par en-tête par un registre de tenants côté serveur : il valide l’URL Jira ou Confluence fournie dans le middleware ASGI avant la création du fetcher, puis ajoute un hook de réponse qui valide les destinations de redirection. L’extrait renforcé montre ces deux contrôles amont ; l’implémentation du validateur est omise. Un registre de tenants côté serveur est une architecture alternative plus forte, pas ce que réalise ce correctif. Les avis ultérieurs de la version 0.22.0 documentent des chemins résiduels distincts ; ne considérez donc pas 0.17.0 comme version minimale pour tout le parc sans les examiner. La validation DNS doit aussi être appliquée au moment de la connexion pour résister au rebinding ; une résolution unique du nom ne suffit pas à fermer la frontière SSRF.^{[1], [2]}

Extrait source: Extrait du correctif amont dans le middleware et le fetcher (parcours Jira ; Confluence dispose de la même protection).

IMPLÉMENTATION VULNÉRABLE

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

PATCH SÉCURISÉ ET ROBUSTE

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()

Liste de Contrôle de Sécurité pour l'Ingénierie

✓N'acceptez pas d'URL de base de tenant dans des en-têtes contrôlés par l'appelant ou non authentifiés ; déduisez le tenant de l'identité authentifiée et de la configuration serveur.^{[1], [2]}
✓N'autorisez que les noms HTTPS Atlassian provisionnés explicitement pour chaque tenant ; rejetez les informations utilisateur, ports inattendus et URL ambiguës.^{[1], [8], [9], [10], [11]}
✓Appliquez la politique de destination aux redirections et à la destination réelle de connexion, pas seulement à l'URL analysée au départ.^{[2], [8]}
✓Restreignez les sorties réseau des services MCP pour bloquer loopback, adresses privées, link-local et métadonnées, sauf besoin explicitement approuvé.^{[12], [1]}
✓Traitez tous les résultats d'outils comme du contenu non fiable ; le texte récupéré depuis Jira ou Confluence ne doit ni élargir les permissions ni autoriser des actions.^{[1], [7]}
✓Auditez chaque parcours qui construit JiraFetcher ou ConfluenceFetcher, y compris les fonctions auxiliaires qui pourraient utiliser une autre session HTTP.^{[2], [8], [9], [10], [11]}
✓Passez à une version ultérieure à 0.17.0 pour corriger ce CVE, puis vérifiez les avis actuels du mainteneur concernant des constats SSRF suivis séparément avant de fixer la version minimale du parc.^{[1], [6], [8], [9], [10], [11]}
✓Distinguez les décisions de version : 0.17.0 corrige le chemin initial de CVE-2026-27826 ; les quatre avis SSRF ultérieurs (CVE-2026-77242, CVE-2026-77267, CVE-2026-77249 et CVE-2026-77274) indiquent 0.22.0 comme version corrigée. Consultez la liste actuelle des avis avant de fixer une version minimale pour tout le parc.^{[6], [8], [9], [10], [11]}