Votre localhost n'est pas privé : sécuriser les environnements de développement contre le SSRF localhost et le rebinding DNS

La plupart des développeurs considèrent localhost comme une frontière de confiance. Tout ce lié à 127.0.0.1 est supposé accessible uniquement par vous. Cette supposition a été régulièrement mise à mal, que ce soit dans les navigateurs, les outils d’IA, les serveurs de développement ou les environnements de conteneurs.

Cet article couvre deux classes d’attaques liées, comment elles touchent les machines de développement, les changements dans les navigateurs des deux dernières années, et ce qu’il faut faire. Il explique aussi où un outil de tunneling comme InstaTunnel peut aider et où il ne le peut pas.

Deux classes d’attaques, une fausse hypothèse

SSRF localhost côté serveur visant la boucle locale. Une application récupère une URL contrôlée par l’attaquant (cible webhook, URL d’image, aperçu de lien) et la pointe vers 127.0.0.1, 0.0.0.0 ou une adresse interne. Le serveur fait alors la requête depuis l’intérieur de la frontière de confiance, vers des services qui n’attendaient pas d’appels extérieurs.

Rebinding DNS fonctionne depuis le navigateur. La victime visite une page de l’attaquant. Le domaine de l’attaquant résout d’abord vers son serveur, puis vers 127.0.0.1, ce qui maintient le traitement des requêtes comme de même origine, même si elles atteignent le service local de la victime. L’avis de Vite décrit cette chaîne : l’attaquant modifie la réponse DNS pour pointer vers 127.0.0.1 ou une autre adresse privée, et un serveur HTTP qui ne valide pas l’en-tête Host ne peut pas faire la différence.

Les deux reposent sur la même mauvaise hypothèse : atteindre un port local signifie que l’appelant est digne de confiance.

La vulnérabilité du jour 0.0.0.0

En août 2024, Oligo Security a révélé “0.0.0.0 Day”, une faille logique dans la gestion des requêtes vers 0.0.0.0 par les principaux navigateurs (Chromium, Firefox, Safari). Oligo l’avait signalée aux éditeurs en avril 2024.

• Le mécanisme. Private Network Access (PNA) était destiné à empêcher les sites publics d’accéder aux adresses privées. Mais 0.0.0.0 n’était pas dans la liste des plages privées ou locales, donc les requêtes y passaient.
• Qui est concerné. La faille a affecté macOS et Linux mais pas Windows. Le chercheur d’Oligo a indiqué que des sites publics pouvaient atteindre n’importe quel port ouvert sur l’hôte, sans pouvoir lire la réponse, ce qui expose surtout à des requêtes aveugles modifiant l’état.
• L’âge. Ce n’est pas une nouveauté récente. La divulgation par Oligo fait écho à un bug signalé à Mozilla en 2006.
• Les correctifs. Chrome a commencé à bloquer 0.0.0.0 dans Chromium 128, avec un déploiement progressif prévu jusqu’à Chrome 133. Apple a modifié WebKit pour le bloquer. Mozilla a modifié la norme Fetch pour le bloquer, mais à l’époque, aucune correction n’était intégrée dans Firefox.

Le déploiement a été inégal. Lorsqu’Oligo a publié son rapport de 2025 sur la faille MCP Inspector (ci-dessous), il mentionnait encore le comportement 0.0.0.0 comme non résolu dans Chromium et Firefox. Ne supposez pas que tous les navigateurs de votre équipe sont protégés.

Exploitation réelle : MCP Inspector

CVE-2025-49596 a touché l’outil MCP Inspector, un outil de développement pour tester les serveurs MCP. Il était classé Critique (CVSS 9.4). Les versions antérieures à 0.14.1 n’avaient pas d’authentification entre le client Inspector et son proxy local. En enchaînant une requête CSRF, un site malveillant pouvait envoyer des commandes à ce proxy et exécuter du code sur la machine du développeur. La version 0.14.1, sortie le 13 juin 2025, a ajouté un jeton de session par défaut et une vérification de l’hôte.

Pourquoi les outils d’IA ont aggravé la situation

Les outils d’IA locaux ont tendance à faire tourner des serveurs HTTP ou WebSocket non authentifiés sur la boucle locale, parce que “c’est uniquement local”. Trois cas récents illustrent ce schéma.

SDK MCP (décembre 2025). CVE-2025-66416 (SDK Python, corrigé en 1.23.0) et CVE-2025-66414 (SDK TypeScript, corrigé en 1.24.0) ont été divulgués car les SDK ne protégeaient pas par défaut contre le rebinding DNS pour les serveurs HTTP. Un serveur MCP non authentifié sur localhost pouvait être atteint depuis un site malveillant, qui pouvait alors invoquer ses outils. Les serveurs utilisant le transport stdio ne sont pas affectés.

ClawJacked (février 2026). Oasis Security a montré que n’importe quel site pouvait détourner un agent OpenClaw local. Les navigateurs ne bloquent pas les connexions WebSocket vers localhost en cross-origin, donc le JavaScript de la page pouvait ouvrir une socket vers la passerelle et deviner son mot de passe. La passerelle exemptait localhost du rate limiting et auto-approvait le pairing, permettant un accès persistant. Une correction a été déployée en environ un jour.

NVIDIA NemoClaw et Ollama (août 2026). Oasis Security a signalé qu’une page web malveillante pouvait prendre le contrôle de l’instance Ollama derrière NemoClaw dans une configuration spécifique. Ollama avait corrigé sa faille de rebinding DNS (CVE-2024-28224) en v0.1.29 en validant l’en-tête Host. Le rapport indique que cette validation est ignorée lorsque Ollama est lié à une adresse non boucle locale, et que le chemin Windows OLLAMA_HOST=0.0.0.0:11434 expose la même vulnérabilité. L’attaquant pourrait alors réécrire le modèle de chat pour insérer des instructions persistantes. La recherche n’a pas de CVE, et aucune exploitation n’a été rapportée en août 2026. Selon le chercheur, une correction a couvert macOS et Linux dans NemoClaw v0.0.35, mais pas Windows et WSL. Vérifiez l’état actuel avant de vous fier à cela.

La leçon est que lier à 0.0.0.0 peut désactiver discrètement des protections applicables uniquement à la boucle locale.

Serveurs de développement et environnements de conteneurs

Vite (CVE-2025-24010). Avant la correction, n’importe quel site pouvait envoyer des requêtes au serveur de développement et lire les réponses, à cause de paramètres CORS permissifs et de l’absence de validation Origin sur les connexions WebSocket. Cela concernait même les serveurs tournant uniquement sur la machine locale. La correction est dans Vite 6.0.9, 5.4.12 et 4.5.6. La nouvelle option server.allowedHosts autorise par défaut localhost, *.localhost et les adresses IP. La documentation de Vite avertit que la mettre à true permet à n’importe quel site d’atteindre votre serveur de développement via rebinding DNS, et recommande une liste explicite.

Docker Desktop (CVE-2025-9074). L’API Engine de Docker était accessible à 192.168.65.7:2375 depuis n’importe quel conteneur, sans authentification. La vulnérabilité, notée 9.3 (CVSS), a été corrigée dans Docker Desktop 4.44.3. Elle concernait Windows et macOS, mais pas Linux, qui utilise un socket local plutôt qu’un port TCP. SOCRadar la classe comme SSRF : une requête forgée depuis un conteneur atteignait une API de contrôle qui supposait que tous les appelants étaient dignes de confiance.

Ce que font maintenant les navigateurs

Le plan initial de Chrome, Private Network Access avec les prévols CORS, a été mis en pause à cause de problèmes de compatibilité. Avant cette suspension, Chrome a ajouté 0.0.0.0/8 aux plages locales de PNA.

Le remplacement est Local Network Access (LNA) :

• Chrome 142 (28 octobre 2025) limite les requêtes de sites publics vers des adresses locales ou boucle locale derrière une invite de permission. D’autres navigateurs Chromium ont suivi.
• Chrome 145 divise la permission en local-network et loopback-network, selon une issue de suivi de l’équipe Chrome. La même issue indique que Chrome 147 étend ces restrictions à WebSocket et WebTransport, et que la politique temporaire de désactivation en entreprise doit disparaître dans Chrome 156.
• Firefox propose une invite similaire. La page de support de Mozilla indique qu’elle s’applique depuis la version 149 pour les utilisateurs avec une Protection renforcée contre le pistage stricte, avec un déploiement progressif à tous à partir de la version 151.

Ce sont de réelles améliorations, mais elles restent une défense en profondeur. Elles invitent l’utilisateur, limitent les requêtes cross-site ; elles ne rendent pas un service local non authentifié sûr. Le rebinding DNS et les logiciels malveillants déjà présents sur la machine sont des problèmes séparés. La solution standard contre le rebinding, comme l’indique la couverture de la recherche NemoClaw, consiste à vérifier les en-têtes Host et Origin côté serveur. Considérez les contrôles du navigateur comme une seconde couche.

Renforcer l’application : une checklist

1. Authentifiez chaque service local, même en boucle locale. Utilisez un jeton aléatoire, pas “c’est uniquement localhost”. CVE-2025-49596 et ClawJacked résultaient tous deux d’une authentification manquante ou faible.
2. Liste blanche de l’en-tête Host et rejetez tout le reste. C’est la défense principale contre le rebinding DNS. N’utilisez jamais un joker ou une configuration “tout autoriser” (Vite allowedHosts: true).
3. Validez Origin sur les requêtes modifiant l’état et lors des upgrades WebSocket. CORS ne couvre pas WebSocket, donc il ne peut pas les protéger.
4. Appliquez des limites de débit aussi sur localhost, et ne validez pas automatiquement le pairing ou l’enregistrement depuis la boucle locale.
5. Liez à 127.0.0.1, pas 0.0.0.0, sauf si vous avez besoin d’accès LAN. Si un environnement de conteneur ou WSL force une liaison plus large, vérifiez quelles vérifications d’hôte restent actives.
6. Privilégiez stdio ou sockets locaux plutôt que TCP pour la communication locale. Le transport stdio de MCP n’est pas exposé à l’attaque du navigateur, et l’architecture Linux de Docker a évité CVE-2025-9074 pour cette raison.
7. Appliquez les patchs. Les versions mentionnées ci-dessus sont le minimum : Vite 6.0.9 / 5.4.12 / 4.5.6, MCP Inspector 0.14.1, SDK Python MCP 1.23.0, SDK TypeScript MCP 1.24.0, Ollama 0.1.29, Docker Desktop 4.44.3.

Renforcer le fetch côté serveur (SSRF localhost)

Si votre backend récupère des URLs fournies par l’utilisateur :

• Privilégiez une liste blanche. La Fiche de prévention SSRF de l’OWASP indique que les listes de refus sont vulnérables. Si possible, comparez l’hôte à des destinations connues et construisez la requête vous-même.
• Bloquez toutes les représentations locales, pas seulement 127.0.0.1. OWASP liste 127.0.0.0/8, 0.0.0.0/8 et ::1/128 pour localhost. Les listes de contournement publiques montrent de nombreuses variantes : 127.1, 0, [::], décimal 2130706433, hexadécimal 0x7f000001, et formes IPv4-mappées IPv6.
• Résolvez, puis validez, puis fixez. Faites une recherche A et AAAA, vérifiez chaque adresse contre vos plages bloquées, puis connectez-vous à l’IP validée. Sinon, un nom de domaine peut passer la validation et se re-resolver vers une adresse privée pour la requête réelle.
• Re-validez les redirections. La cible d’une redirection est une seconde requête qui doit subir les mêmes vérifications.
• Bloquez les plages locales et privées, y compris l’adresse de métadonnées cloud 169.254.169.254.

Où un tunnel peut aider

Un tunnel inverse votre exposition : au lieu d’un service localhost accessible uniquement par votre navigateur, vous avez un service accessible à tous via l’URL. Utile pour webhooks, callbacks OAuth, démos et tests MCP, mais cela rend la checklist ci-dessus obligatoire.

Un tunnel ne résout pas ces problèmes. Il ne peut pas ajouter la validation Host à votre serveur de développement ni l’authentification à votre endpoint MCP. Ce qu’il peut faire, c’est mettre un contrôle d’accès devant le service local, pour ne pas dépendre uniquement des paramètres par défaut du service. Selon la documentation d’InstaTunnel :

• Authentification en bordure. --password et --auth user:pass protègent un tunnel. Ces options nécessitent un plan Pro ou Business. Depuis CLI 1.1.24, le mot de passe et l’auth Basic sont appliqués avant que les requêtes ne soient transférées vers votre machine.

instatunnel 3000 --subdomain acme-qa --auth qa:review-secret

• Tunnels MCP avec token Bearer. --mcp nécessite un plan Pro ou Business. La documentation montre comment générer un token avec node -e "console.log(require('crypto').randomBytes(32).toString('hex'))" et l’utiliser dans un en-tête Authorization: Bearer. Votre serveur MCP doit faire respecter le token ; le client ne le nécessite pas par défaut.

instatunnel 8787 --mcp --transport v2 --subdomain mymcp

• Politiques de trafic. La documentation des politiques de trafic d’InstaTunnel décrit des règles d’autorisation et de refus IP par CIDR, des règles d’en-tête, des limites par IP/API-clé/utilisateur (renvoyant 403 ou 429 en cas de blocage), et des enregistrements d’audit. Gérés par les administrateurs via /admin/policies.
• Visibilité et nettoyage. --logs (Pro/Business) récupère les logs, et --kill <subdomain> arrête un tunnel. Pour les liens QA, la documentation recommande de faire tourner les identifiants et d’arrêter le tunnel après revue.

Un détail pratique : si votre tunnel transmet son nom d’hôte public dans l’en-tête Host, une liste blanche comme allowedHosts de Vite rejettera cette requête jusqu’à ce que vous ajoutiez ce nom d’hôte précis. Ajoutez le nom d’hôte spécifique que vous contrôlez, pas un joker ni true. Vérifiez ce que votre tunnel envoie avant de vous y fier.

Résumé

• 0.0.0.0 Day est une faille de navigateur de 2024, corrigée de façon inégale. Elle a été exploitée concrètement contre des outils de développement comme MCP Inspector.
• Rebinding DNS revient régulièrement dans les outils de développement, d’Ollama en 2024 à MCP SDKs en 2025 puis NemoClaw en 2026. La solution est toujours côté serveur : authentification, validation de Host et Origin.
• Les invites de permission du navigateur (Chrome 142+, Firefox 149+) réduisent l’exposition mais ne remplacent pas ces vérifications.
• Les fetch côté serveur doivent avoir des listes blanches, une résolution complète des adresses et des connexions fixées.
• Les tunnels doivent ajouter authentification et contrôle d’accès devant votre service, jamais en être la seule barrière.