DeepSeek Harness permettait à un attaquant en environnement sandbox d'exécuter des commandes arbitraires simplement en modifiant l'en-tête HTTP Host en 127.0.0.1, ce qui lui confère un score de 9,4 sur l'échelle CVSS. Cette faille montre comment une seule décision de confiance mal placée peut transformer une barrière de protection en une porte dérobée ouverte.

Comment le bug s'est glissé dans le code

Le code vulnérable se trouve dans une fonction unique qui lit l'en-tête Host de la requête et, si la valeur est égale à l'adresse de bouclage (loopback), traite la requête comme provenant de la machine locale.

Un attaquant capable d'exécuter du code à l'intérieur de la sandbox n'a pas besoin d'une charge utile sophistiquée. En envoyant une seule requête HTTP avec Host: 127.0.0.1, le backend croit que l'appel provient de l'hôte lui-même et ignore toutes les invites de sécurité, les vérifications de limitation de débit (rate-limiting) et les étapes de validation des commandes. Résultat : une exécution de commandes sans restriction, sans aucune interaction supplémentaire requise.

Pourquoi faire confiance aux en-têtes est dangereux

Les en-têtes sont des chaînes de caractères en texte clair fournies par l'appelant. Que le champ s'appelle Host, X-Forwarded-For ou tout autre nom personnalisé, le client peut lui attribuer la valeur qu'il souhaite. La seule source de vérité fiable concernant l'origine réelle d'une connexion est la couche de transport — l'adresse IP source du socket que le système d'exploitation enregistre lors de la finalisation du handshake TCP.

Lorsqu'une application décide de faire confiance à un en-tête sans confirmer qu'un proxy connu et correctement configuré l'a injecté, elle remet les clés du royaume à un attaquant. Le bug de DeepSeek Harness est un exemple d'école de cette erreur.

Impact dans le monde réel : l'exemple shell.online

Le projet open-source shell.online, qui propose un terminal basé sur le web, a récemment documenté le même piège. Il utilise un indicateur de configuration appelé TRUST_PROXY :

  • TRUST_PROXY = 0 – l'application ignore l'en-tête X-Forwarded-For et se fie à l'adresse distante du socket. Cela empêche un client de forger une adresse IP pour contourner les limites de débit ou de se faire passer pour un utilisateur de confiance.
  • TRUST_PROXY = 1 – l'application fait confiance à l'en-tête X-Forwarded-For pour identifier le client. Si le service n'est pas derrière un véritable proxy qui assainit cet en-tête, un attaquant peut fournir une nouvelle adresse IP à chaque requête, réinitialisant ainsi efficacement toute limitation de débit par IP.

Le bug de DeepSeek reflète ce scénario : le code faisait confiance à Host comme si un proxy l'avait défini, alors que le service pouvait être accédé directement.

Ce que les développeurs doivent faire dès maintenant

  1. Auditez chaque endroit où vous lisez des en-têtes fournis par le client. Identifiez les en-têtes que vous considérez comme faisant autorité (par exemple, Host, X-Forwarded-For, X-Real-IP) et vérifiez qu'un proxy de confiance est garanti de les réécrire avant qu'ils n'atteignent votre application.
  2. Liez les décisions de sécurité à l'adresse du socket dans la mesure du possible. Utilisez l'IP source fournie par le système d'exploitation pour l'authentification, la limitation de débit et les contrôles d'accès.
  3. N'activez les indicateurs de confiance du proxy que lorsqu'un reverse proxy correctement configuré se trouve devant le service. Si vous exécutez l'application directement, laissez ces indicateurs désactivés.
  4. Documentez la topologie de déploiement requise dans le README ou le guide de déploiement de votre projet, afin que les utilisateurs qui auto-hébergent le service soient informés de l'exigence de confiance du proxy.
  5. Utilisez des outils d'analyse statique ou de revue de code qui signalent l'utilisation directe d'en-têtes pour des décisions de sécurité sans logique de validation de proxy associée.

À surveiller ensuite

Les communautés qui proposent des services web auto-hébergés sont susceptibles de revoir leurs propres paramètres de confiance du proxy après cet incident.

La leçon fondamentale est sans appel : ne laissez jamais un morceau de texte que n'importe qui sur Internet peut écrire dicter la posture de sécurité de votre système. Faites confiance à la couche réseau, pas à la couche requête.