Quand le correctif SSRF ne tient pas : rebinding DNS et garde-fous contournés

What is this?

Deux divulgations publiées en juillet 2026 pointent le même constat inconfortable : livrer un correctif SSRF dans un framework d’agent ne signifie pas être à l’abri de la SSRF. Une faille de type SSRF (server-side request forgery) permet à un attaquant de faire récupérer par le serveur une URL de son choix — le plus souvent pour atteindre un service interne ou un point de terminaison de métadonnées cloud comme 169.254.169.254, susceptible de renvoyer des identifiants IAM.

Le 2026-07-10, un avis GitHub concernant le serveur MCP mcp-atlassian a décrit une manière de vaincre un garde-fou SSRF déjà corrigé à l’aide du rebinding DNS. Séparément, un avis de juillet 2026 pour Langflow (le générateur visuel de pipelines LLM) a montré que certains composants de récupération hérités effectuaient des requêtes sans passer par la protection SSRF ajoutée dans une version antérieure. Produits différents, mécanismes différents, une même leçon : la frontière qui décide si une requête est autorisée doit être exactement la même que celle qui ouvre réellement la socket.

How it works

Les deux cas échouent de façon complémentaire.

Dans mcp-atlassian, le correctif avait ajouté un contrôle validate_url_for_ssrf. Lorsqu’une requête portait un hôte influencé par l’attaquant dans un en-tête X-Atlassian-*-Url, le garde-fou résolvait ce nom une fois, vérifiait que chaque adresse renvoyée était une IP publique (globale), et renvoyait un verdict autorisé/refusé. Le problème tient à ce qu’il renvoyait : un verdict, et non l’IP qu’il venait d’approuver. Le code qui effectue réellement la requête sortante était alors construit à partir du nom d’hôte brut et le re-résolvait au moment de la connexion. Cet écart entre la vérification et l’usage est une course classique time-of-check to time-of-use (TOCTOU) (CWE-367). Un attaquant qui contrôle le DNS faisant autorité pour son domaine peut répondre à la première résolution par une IP publique (le garde-fou passe) et à la seconde par une adresse interne (la socket s’y connecte). Le résultat est une SSRF (CWE-918) sur la version corrigée.

# TOCTOU avec rebinding DNS — pourquoi « valider puis récupérer » ne suffit pas

  t0  garde : resolve(host) -> 93.184.216.34  (publique) -> PASSE, verdict jeté
  t1  fetch : resolve(host) -> 169.254.169.254 (métadonnées) -> la socket se connecte ICI

  La vérification et la connexion ont résolu le MÊME nom vers des IP DIFFÉRENTES.

Le cas de Langflow est plus simple et, d’une certaine manière, plus courant : le garde-fou existait, mais tous les chemins n’y passaient pas. Les protections SSRF introduites dans une version antérieure ne couvraient pas certains composants de récupération hérités (un lecteur RSS et un connecteur de métarecherche), qui émettaient encore des requêtes vers une URL fournie par l’utilisateur, directement. Comme ces composants peuvent s’exécuter en mode agentique, l’URL n’a même pas besoin de venir d’un opérateur humain : elle peut arriver par injection de prompt indirecte dans le contenu que l’agent traite. Aucun serveur de rebinding fonctionnel ni payload n’est reproduit ici ; le propos est structurel, pas une recette.

Why it matters

Les deux failles vivent dans des logiciels dont tout le rôle est de laisser un modèle de langage atteindre l’extérieur : un serveur MCP qui dialogue avec Atlassian, un générateur de pipelines qui récupère des flux et des résultats de recherche. Dans ce contexte, l’« utilisateur » qui fournit une URL est fréquemment le modèle, et les entrées du modèle peuvent être façonnées par un ticket, une page web ou un document qu’il vient de lire. Une primitive SSRF ici n’est pas un bug réseau abstrait : c’est une ligne directe entre une entrée d’agent non fiable et des identifiants de métadonnées cloud et des services internes, ce qui correspond aux risques liés aux outils et intégrations de l’OWASP LLM Top 10.

La raison plus profonde tient à ce que ce sont deux histoires de correctif incomplet. Un CVE a été déposé, un patch livré, les tableaux de bord sont passés au vert — et la protection ne tenait toujours pas, parce que la validation et la connexion n’étaient pas d’accord sur l’adresse réellement contactée, ou parce qu’un second chemin de code ne consultait jamais le validateur. C’est précisément le type de régression que les contrôles automatisés « est-ce corrigé ? » laissent passer.

Defenses

Les mitigations durables pour cette classe consistent à rendre la décision validée autoritaire jusqu’à la socket :

1. Épingler l’IP validée à la connexion. Faire renvoyer par le contrôle SSRF l’adresse précise qu’il a approuvée, puis forcer la requête sortante à se connecter à cette IP (résolveur personnalisé, getaddrinfo mis en cache, ou adaptateur qui surcharge la résolution) tout en préservant l’en-tête Host d’origine. Cela ferme la fenêtre de rebinding DNS puisqu’il n’y a plus de seconde résolution à empoisonner.
2. Un point de passage unique pour toute sortie. Router chaque requête sortante — y compris les composants hérités, optionnels et « de confort » — via le même client HTTP validé. Des bugs comme celui de Langflow surviennent quand un chemin latéral oublie que le garde-fou existe.
3. Bloquer les cibles sensibles au moment de la connexion, pas seulement au parsing. Refuser les plages link-local, loopback et privées (et l’IP de métadonnées) à l’ouverture de la socket, pour qu’un nom résolu tardivement ne puisse pas contourner une allowlist basée sur les noms.
4. Traiter les URL fournies par l’agent comme contrôlées par l’attaquant. Supposer que toute URL reçue par un outil a pu être orientée par du contenu ingéré par le modèle ; valider à la frontière de l’outil comme si elle venait d’un internaute anonyme.
5. Moindre privilège sur le runtime. Préférer IMDSv2 (ou l’équivalent cloud) et restreindre étroitement les rôles d’instance, afin qu’une récupération de métadonnées réussie rapporte peu.

Status

Élément	Référence	Date	Notes
SSRF mcp-atlassian (en-tête)	CVE-2026-27826 / GHSA-7r34-79r5-rcc9	2026	SSRF X-Atlassian-*-Url d’origine ; correctif ajoutant validate_url_for_ssrf
Contournement par rebinding	GHSA-489g-7rxv-6c8q	2026-07-10	Correctif incomplet ; TOCTOU (CWE-367) + SSRF (CWE-918) ; verdict sans IP épinglée ; corrigé en 0.22.0
SSRF Langflow	CVE-2026-10546	2026-07	Composants de récupération hérités contournant la protection ajoutée en 1.9.3 ; atteignable via le mode outil agentique
Classe	OWASP LLM Top 10	2025	Conception d’outils/intégrations non sécurisée, agence excessive

Tous les détails ci-dessus proviennent des avis éditeurs et des enregistrements CVE publics ; les deux problèmes sont divulgués. L’enseignement dépasse ces deux produits : tout framework d’agent qui récupère des URL doit supposer que valider un nom d’hôte puis le re-résoudre — ou laisser un second chemin de récupération sans garde-fou — rouvre exactement la brèche que le patch devait fermer.