CVE-2026-80347 in mcp-fetch
Résumé
par VulDB • 26/08/2026
mcp-fetch vérifie la cible de l'appel fetch par rapport à son mécanisme de protection contre les SSRF sans supprimer les crochets entourant une adresse IPv6 littérale. isSafeUrl extrait le nom d'hôte (hostname) depuis l'URL analysée ; pour un littéral tel que http://[::1]/, cela renvoie la chaîne entre crochets, puis la teste avec net.isIP. Cette fonction retourne zéro pour une valeur entre crochets, ce qui fait sauter entièrement la branche contenant les vérifications d'adresses privées. Le mécanisme de protection (guard) revient alors à résoudre le nom d'hôte ; comme la chaîne entre crochets n'est pas un nom résolvable, aucune adresse n'est renvoyée et la cible est considérée comme sûre. Le client HTTP supprime ensuite les crochets et établit la connexion. Étant donné que l'adresse peut être fournie sous forme mappée en IPv4 (IPv4-mapped), le même chemin permet d'accéder à toute cible IPv4, y compris aux points de terminaison de métadonnées link-local, que les vérifications loopback et privées étaient censées exclure. isPrivateIPv6 ne gère pas non plus le préfixe ::ffff:, donc la forme mappée passerait encore même si les crochets étaient supprimés. La cible du fetch étant fournie en tant qu'argument d'outil, un attaquant capable d'influencer ce que le modèle demande peut lire les réponses internes et les réinjecter dans le contexte du modèle.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.