DeepSeek Harness CVE-2026-82533 : un agent en bac à sable désactive son propre bac à sable avec une seule commande

VulnCheck a publié CVE-2026-82533 le 8 septembre 2026 : un contournement critique de l'authentification qui permettait à un agent de codage IA de désactiver son propre bac à sable avec une seule commande shell. Le logiciel est DeepSeek Harness, l'environnement d'exécution local open source de DeepSeek pour les agents de codage, qui, selon la Cloud Security Alliance, a recueilli environ 215 000 étoiles GitHub en quelques semaines ; toutes les versions antérieures à 0.1.2-alpha.1 sont affectées. Il déterminait si un appelant était local à partir de l'en-tête Host fourni par l'appelant lui-même, de sorte qu'une requête pouvait prétendre provenir de la boucle locale. Comme son bac à sable limitait les écritures de fichiers mais pas les connexions réseau en boucle locale, un agent confiné pouvait appeler l'API de contrôle non authentifiée du harness sur le port 3080 et basculer sa session en danger-full-access avec les approbations désactivées. VulnCheck lui attribue un score de 9,4, critique ; aucune exploitation en conditions réelles n'est revendiquée. Cet enregistrement est une entrée d'un jeu de données public d'incidents liés à l'IA, et l'Orca AI Incident Archive contient l'ensemble complet des enregistrements, avec les dates, les niveaux de gravité et les sources de chaque entrée.

La vérification qui demandait à une requête ce qu'elle était

Le composant vulnérable est l’API locale de contrôle d’agent du harness, le petit service HTTP que l’interface web et la ligne de commande utilisent pour piloter une session en cours. Selon la note de recherche de la Cloud Security Alliance du 10 septembre 2026, qui s’appuie sur l’analyse d’OX Security, l’entreprise qui a découvert la faille, ce service écoutait par défaut sur 127.0.0.1 au port 3080 et prenait sa décision de confiance dans une fonction que la note nomme isTrustedApiRequest. La fonction lisait l’en-tête HTTP Host et accordait l’accès lorsque la valeur correspondait à un nom de bouclage tel que localhost ou 127.0.0.1. Un en-tête Host est une métadonnée écrite par le client ; il ne dit rien sur l’origine de la connexion TCP. The Hacker News, citant la source concernée le 9 septembre 2026, rapporte que la vérification n’a jamais examiné l’origine de la connexion et qu’un commentaire dans le même fichier indique que la vérification « n’est pas une couche d’authentification ».

C’est tout le sens de CWE-807, la confiance accordée à des entrées non fiables dans une décision de sécurité, et c’est ce que décrit le bulletin publié par VulnCheck : un en-tête Host de loopback fourni par le client est accepté au lieu de valider l’origine réelle de la connexion TCP.

Ce qui a transformé un contrôle défaillant en voie d’évasion, c’est le fait que le harnais remettait à l’agent ses propres clés. The Hacker News rapporte que le harnais transmet au shell de l’agent l’adresse de l’interface de contrôle et l’identifiant de la session en cours, de sorte qu’une commande n’a besoin de découvrir ni l’un ni l’autre. Le bac à sable, quant à lui, couvrait un canal mais pas l’autre : la référence en ligne de commande de la version concernée indique que, dans la configuration par défaut, les écritures restent à l’intérieur de l’espace de travail et des dossiers temporaires, tandis que les lectures et l’accès au réseau ne sont pas confinés.

Pourquoi les demandes d'approbation ne l'ont pas arrêté

Le harnais avait bien des invites d’approbation, et elles n’ont pas tant été contournées qu’elles étaient inapplicables. The Hacker News rapporte que, dans la version concernée, une approbation n’était demandée que lorsqu’une commande cherchait à obtenir un accès plus large que celui dont la session disposait déjà. L’appel d’escalade ne cherchait rien de tel ; il modifiait le paramètre de la session. Un agent qui l’a exécuté est passé dans un mode que OX Security appelle danger-full-access, avec les invites d’approbation définies sur never, et a continué à s’exécuter en tant qu’utilisateur qui avait lancé le harnais, en dehors de la sandbox.

La preuve d’OX Security concernant cette frontière était une paire contrôlée. The Hacker News rapporte que l’entreprise a exécuté deux sessions à partir de paramètres par défaut identiques et a donné aux deux la même commande : la session qui a effectué l’appel a écrit dans un dossier extérieur à son espace de travail, et l’autre a été bloquée.

La seconde voie, et la condition préalable dont elle avait besoin

La même vérification manquante exposait le harnais à des appelants qui ne se trouvaient pas du tout dans un bac à sable, mais seulement dans une condition que la configuration par défaut ne créait pas. La ligne de commande refusait de lier l’API à toutes les interfaces réseau, de sorte que le port n’était joignable depuis ailleurs que si un utilisateur l’avait déjà transféré — via un tunnel, un proxy inverse, un transfert SSH ou la fonctionnalité de transfert de port propre à un éditeur, selon The Hacker News ; la note de la Cloud Security Alliance répertorie le même ensemble. Lorsque cette condition préalable était remplie, indique l’avis de VulnCheck, un appelant sans identifiants pouvait créer des sessions, exécuter des commandes arbitraires et exfiltrer des transcriptions de conversations stockées. The Hacker News ajoute que la même interface servait une requête qui télécharge l’intégralité du journal d’une session.

La voie en bac à sable nécessite une autre condition préalable : un texte que l’agent lira et sur lequel il agira. La note de la Cloud Security Alliance décrit un agent confiné traitant une invite fournie par un attaquant, intégrée dans un commentaire de code, un fichier README ou le texte d’un ticket. Aucune des deux voies ne nécessite une clé volée, et la note fait observer que la voie distante ne nécessite aucune interaction avec le modèle une fois le port exposé.

La population exposée est donc quiconque a exécuté le harnais en 0.1.1-rc.2 ou une version antérieure avec les paramètres par défaut, un ensemble que le nombre d’étoiles ne fait qu’effleurer. The Hacker News a compté plus de 216 000 étoiles le 9 septembre 2026 et a averti qu’une étoile est un signet plutôt qu’une installation.

Ce qui est établi, et ce qui ne l’est pas

Il ressort du dossier CVE lui-même : VulnCheck est l’autorité de numérotation, a réservé l’identifiant le 29 août 2026 et a publié l’enregistrement le 8 septembre à 16:59 UTC ; la faiblesse est CWE-807 ; la plage affectée couvre toutes les versions antérieures à 0.1.2-alpha.1 ; et le mérite revient à Nir Zadok et Moshe Siman Tov Bustan. Les deux scores que porte l’enregistrement, 9.4 selon CVSS 4.0 et 9.6 selon CVSS 3.1, proviennent de VulnCheck et non d’un second évaluateur indépendant — NVD liste les deux métriques avec VulnCheck comme source — il s’agit donc d’une seule évaluation exprimée dans deux référentiels, et non de deux évaluations concordantes.

Établi à partir du dépôt : le commit de correctif 3e24087, intitulé « fix(web): authenticate the browser Host API », est daté du 24 août 2026 et ajoute un module d’authentification du navigateur ainsi que 210 lignes de tests de bout en bout pour le nouveau flux, selon l’API GitHub. La version publiée étiquetée dsh-v0.1.2-alpha.1 a suivi le 27 août à 17 h 06 UTC.

Non établi : utilisation. Ni l’enregistrement CVE, ni l’avis de VulnCheck, ni les notes de version de DeepSeek ne décrivent une exploitation en conditions réelles, et la NVD consigne la maturité d’exploitation comme non définie. Le modèle EPSS de FIRST attribuait à la faille une probabilité d’exploitation de 1,24 % au cours des 30 jours suivants, au 68,9e centile, dans le flux daté du 27 octobre 2026. L’archive ne consigne aucun préjudice réel pour cette entrée et lui attribue une confiance A, bien documenté, avec des sources primaires concordantes.

Les dates, y compris deux rapports qui sont arrivés en premier

{{1}}Deux développeurs sont parvenus à la même conclusion avant qu’il n’y ait une CVE à citer.{{/1}} {{2}}The Hacker News rapporte un billet publié sur le forum de discussion du projet lui-même le 13 août 2026, montrant qu’un processus encore confiné par le bac à sable atteint l’interface locale et bascule la session vers danger-full-access, avec les résultats des tests, ainsi qu’un second billet le 14 août listant les requêtes que cette interface a acceptées sans identifiants.{{/2}} {{3}}Le second billet indiquait également que le projet ne disposait ni d’un fichier de politique de sécurité ni d’une voie privée pour signaler une faille ; The Hacker News a vérifié le 9 septembre et constaté que le fichier de politique de sécurité manquait toujours.{{/3}}

La chronologie d’OX Security situe la transmission de son rapport à VulnCheck au 24 août 2026 — la même date que celle que GitHub associe au commit de correction. Le message du commit ne dit rien du rapport, et le compte public d’OX Security, tel que le décrit The Hacker News, ne mentionne pas les publications antérieures de la communauté. Le fait que les deux événements du 24 août aient été liés n’est pas affirmé dans les sources publiques, et cet article ne le suppose pas.

L’écart entre la correction et la divulgation n’est pas inhabituel. La note de la Cloud Security Alliance indique qu’OX Security a confirmé la correction le 30 août, neuf jours avant que VulnCheck ne publie la CVE.

Où le correctif a été appliqué, et où il ne l’a pas été

Le tag GitHub et le registre de paquets n’ont pas évolué ensemble, et c’est le point à connaître si vous avez installé le harnais comme ses instructions le suggèrent. Le paquet en ligne de commande, @deepseek-ai/dsh, a été publié en version 0.1.1-rc.2 le 21 août 2026, puis plus rien jusqu’à la version 0.1.2-alpha.2 le 30 août. La version 0.1.2-alpha.1, celle que la CVE désigne comme le correctif, est totalement absente du registre, de sorte que la première version corrigée installable n’est arrivée que trois jours après le correctif. Les métadonnées du registre npm ont été consultées pour cet article le 28 octobre 2026 ; The Hacker News a signalé ce même décalage le 9 septembre.

Les notes de version ne la présentaient pas comme une version de sécurité. Elles indiquent, parmi les changements de routine, que l’interface web exige désormais une authentification par jeton à usage unique pour l’accès réseau, sans référence CVE ni avis de sécurité, et The Hacker News n’a trouvé aucun avis de sécurité dans la liste des avis du dépôt le 9 septembre. Le mécanisme, tel que le décrit la Cloud Security Alliance : le harnais imprime un jeton à usage unique au démarrage, le navigateur échange ce jeton contre un cookie signé, et chaque appel ultérieur doit présenter le cookie — la confiance étant liée à un secret émis au démarrage du processus plutôt qu’à une origine réseau déclarée.

Les builds tiers sont le point faible. Les wrappers de bureau embarquent leur propre copie du harness, donc la version qu’un utilisateur exécute relève du choix du mainteneur du wrapper ; The Hacker News a trouvé un build Windows figé sur 0.1.1-rc.2 fin août, passé à 0.1.3-alpha.1, qui contient le correctif, le 6 septembre.

Le bac à sable lui-même est inchangé. En lisant la référence de ligne de commande 0.1.2-rc.1, The Hacker News a trouvé la même déclaration selon laquelle les accès en lecture et au réseau ne sont pas confinés, et a constaté que le shell de l'agent reçoit toujours l'adresse d'interface. Aucune source dans ce reportage n'indique si un agent travaillant à l'intérieur de son espace de travail peut encore obtenir une session valide sous le nouveau schéma, une question que la documentation du correctif elle-même laisse ouverte.

Ce que recommandent les sources du dossier

• Considérez toute installation en 0.1.1-rc.2 ou antérieure comme affectée, quel que soit son mode d'empaquetage, y compris une copie intégrée dans un wrapper de bureau.

• Installez la version 0.1.2-alpha.2 ou ultérieure depuis npm ; la version la plus récente sur le registre au 27 octobre 2026 était 0.2.2-alpha.2.

• Si vous ne pouvez pas effectuer la mise à niveau, arrêtez l’interface web lorsqu’elle n’est pas utilisée et supprimez tout tunnel, proxy ou redirection de port qui atteint le port 3080.

• Vérifiez si le port 3080 est joignable depuis ailleurs que le loopback, y compris via le transfert de ports de conteneur, les proxys inverses et les tunnels SSH.

• Consignez les élévations de privilèges et les changements de mode d’approbation au niveau du harnais, car l’attaque a fonctionné en faisant passer une élévation non autorisée pour une activité de routine.

Les cinq proviennent de la note de la Cloud Security Alliance et des articles de The Hacker News ; l'enregistrement CVE lui-même ne comporte aucune indication de remédiation au-delà de la version corrigée.

Pourquoi la Cloud Security Alliance l’interprète comme un modèle

La note de la Cloud Security Alliance place cette CVE aux côtés de deux autres défaillances de confinement d’agents de codage qu’elle a documentées en 2026 : GuardFall, le 1er juillet, où dix des onze agents de codage open source populaires ont pu être amenés à exécuter des commandes shell que leurs garde-fous étaient censés bloquer, et les conclusions du 22 juillet sur le transfert de confiance, où un agent confiné a écrit un fichier qu’un composant de confiance extérieur au bac à sable a ensuite exécuté. La note précise explicitement que ces trois cas proviennent de ses propres recherches et non d’une étude exhaustive du marché, et que l’on n’a pas établi si ce schéma se généralise au-delà des agents qu’elle a examinés. Ce qu’elle avance, en revanche, c’est que les défaillances se situent à différents niveaux — les garde-fous de commandes, la confiance en aval et, désormais, l’authentification du plan de contrôle — et c’est pourquoi elle recommande de traiter l’architecture de bac à sable comme une question d’approvisionnement plutôt que comme une exigence satisfaite.

La documentation de sécurité de DeepSeek elle-même ne contredit pas cette lecture. Le fichier SAFETY.md du dépôt indique que le logiciel « n'a pas fait l'objet d'un audit de sécurité et ne doit pas être considéré comme sûr ou prêt pour la production », et que le bac à sable, les invites d'approbation et les contrôles de permissions « ne garantissent pas l'isolation ni n'empêchent les dommages ». La faille d'authentification qui permettait à un agent de s'échapper via l'API de contrôle est corrigée dans les versions actuelles. L'asymétrie qui rendait cette échappée courte — une frontière autour des écritures et rien autour du réseau — demeure une limitation déclarée du bac à sable plutôt qu'un défaut que le correctif entendait corriger.