Fetch a un garde-fou. Ce n’est toujours pas un pare-feu.
La version MCP du 11 octobre refuse par défaut les destinations non publiques. Le DNS rebinding et les noms résolus seulement par un proxy restent hors de cette garantie.
Faits vérifiés le 12 octobre 2026
La version MCP du 11 octobre refuse par défaut les destinations non publiques. Le DNS rebinding et les noms résolus seulement par un proxy restent hors de cette garantie. PR #5033
La requête part d’ailleurs
Une URL arrive dans une conversation avec une IA. On croit demander la lecture d’une page publique. Pourtant, la connexion part de la machine qui exécute le serveur Fetch, pas de la personne qui saisit l’adresse. Voilà le problème : l’outil emprunte la portée réseau de son hôte. Ma lecture de cette version des serveurs de référence MCP est qu’un comportement par défaut utile a changé, mais que la machine a toujours besoin de sa propre frontière.
Ce qui est publié, sans promesse supplémentaire
Le registre officiel de la version, publié le 11 octobre à 02:40 UTC, inclut mcp-server-fetch 2026.10.10 parmi sept paquets de référence publiés. Il cite la pull request #5033 : refuser par défaut les adresses privées, de boucle locale et de métadonnées. Cette PR a été fusionnée le 5 octobre. C’est une publication de paquet, pas l’affirmation que chaque déploiement MCP possède ce filtre. Un ancien processus ne reçoit pas une nouvelle politique parce qu’une page de version existe.
Où se trouve le contrôle
Les mainteneurs décrivent un hook HTTP qui résout le nom d’hôte avant chaque requête. Si une seule des adresses obtenues n’est pas publique, la requête est refusée. Le contrôle couvre robots.txt, la page et chaque étape de redirection, pour l’outil comme pour le prompt. Une première URL publique n’autorise donc pas une redirection ultérieure vers le réseau interne. L’option de démarrage documentée --allow-private-ips désactive le filtre. C’est une configuration de l’hôte, pas un argument que le modèle ajoute à un appel Fetch.
Deux limites derrière une formule simple
La source décrit deux limites. Le hook résout le nom, puis la connexion HTTP le résout à nouveau. Le DNS rebinding peut donner deux réponses différentes : vérifier une adresse publique ne signifie pas se connecter à cette adresse. De plus, un nom que le serveur ne peut pas résoudre est transmis au transport. Un proxy peut le résoudre ailleurs. Le contrôle ne certifie pas une destination qu’il n’a jamais résolue. Ces limites sont documentées, pas reproduites par moi. Je n’ai ni installé ni exécuté le paquet.
Analyse : placer la garantie sur la connexion
Ma conclusion est plus étroite que « navigation sûre pour les agents » : ce filtre ferme des chemins par défaut importants vers les adresses non publiques, tandis qu’une politique de sortie distincte doit contraindre la connexion réelle. Lors d’une revue de déploiement, je demanderais quel résolveur, proxy et règle réseau déterminent la destination finale. Une liste d’URL autorisées ne répond pas à cela. Une étiquette read-only non plus : lire peut envoyer une requête sensible, et la réponse peut contenir des instructions hostiles. Le texte reçu est une preuve, jamais une autorisation de changer la tâche.
Un plan de réception reproductible, pas un rapport de test
Avant déploiement, utilisez une machine jetable sans secrets et un point public que vous contrôlez. Essayez une page publique normale, une URL de boucle locale directe, une redirection publique vers cette boucle et un nom résolu seulement par le proxy configuré. Notez version exacte, options, proxy et destination demandée. Attendez les refus documentés lorsque le filtre peut résoudre l’adresse ; ne qualifiez pas le cas proxy-only de protégé. Étudiez ou testez séparément la frontière du connecteur pour le DNS rebinding. Ne sondez ni le service interne d’autrui ni un vrai service de métadonnées.
Ce que je conserverais dans le ticket
La pièce utile est un petit registre : version du serveur observée ; absence de l’option de contournement ; preuves des refus de redirection ; politique réseau à la connexion ; et les deux limites restantes. Séparez « les mainteneurs rapportent » de « nous avons observé ». La PR rapporte des tests de protocole et un essai avec Inspector, mais précise qu’aucun client LLM n’y a été testé. C’est une preuve utile avec une portée déclarée. Un numéro nomme une version ; il ne remplace pas les preuves du déploiement.
Registre de décision illustratif, pas du code de sécurité exécutable
requête → résolution → refus d’une adresse non publique
↓
la connexion HTTP résout à nouveau
↓
destination réelle : politique de sortie