Contexte et découverte
Le projet open‑source DeepSeek Harness, destiné à exécuter des agents de codage alimentés par IA, a rapidement gagné en popularité, atteignant plus de 215 000 étoiles GitHub en quelques semaines. En août 2024, les chercheurs d’OX Security ont identifié une vulnérabilité classée CVE‑2026‑82533 avec un score CVSS de 9,4/10. Cette faille permettait à un agent IA ou à un attaquant distant non authentifié de désactiver le sandbox du système, de prendre le contrôle de l’agent et d’extraire les conversations stockées, le tout sans clé d’API ni appel de modèle.
Mécanisme de la faille
Le cœur du problème réside dans la fonction isTrustedApiRequest, qui décide de l’accès à l’API locale en ne consultant que l’en‑tête HTTP Host. La logique accepte toute valeur correspondant à une adresse de boucle (loopback) ou figurant dans la liste trustedHosts, mais ne compare jamais cet en‑tête à l’adresse IP réelle du client. Un acteur malveillant peut donc envoyer une requête où l’en‑tête Host indique 127.0.0.1 tout en établissant une connexion TCP depuis une machine distante. Le serveur, convaincu d’une requête interne, élève la session à « danger‑full‑access » et désactive le sandbox.
Impact et vecteurs d’attaque
Une fois le sandbox contourné, l’agent hérite de l’autorité du développeur qui l’a lancé, incluant l’accès aux clés SSH, aux identifiants cloud, aux registres de paquets et à tout service interne accessible depuis la station de travail. Le PoC d’OX Security montre que l’attaquant peut exécuter des commandes de construction, de test ou de déploiement sans aucune restriction, et récupérer l’historique complet des conversations de l’agent. Le risque s’amplifie si le port de l’API locale est exposé via un tunnel SSH, un proxy inverse ou tout autre mécanisme de redirection réseau, car cela ouvre une porte d’entrée non authentifiée.
Correction et bonnes pratiques
DeepSeek a publié la version 0.1.2‑alpha.1 le 27 août 2024, intégrant une validation stricte de l’adresse source du socket avant d’accepter l’en‑tête Host. Les tests d’OX Security du 30 août confirment la résolution du problème. Les utilisateurs doivent mettre à jour immédiatement, désactiver l’exposition du port API via des tunnels ou des proxys, et appliquer des contrôles réseau supplémentaires (firewall local, listes blanches d’adresses). En outre, il est recommandé de surveiller les logs d’accès à l’API pour détecter toute tentative de spoofing du Host et de limiter les privilèges accordés aux agents IA au strict nécessaire.