DeepSeek Harness : comment un simple en-tête HTTP peut mener à une RCE notée 9,8

QVD-2026-57410 désigne une vulnérabilité critique signalée dans DeepSeek Harness (DSH) 0.1.1-rc.2. Selon les rapports liés à QiAnXin, il s’agit d’une exécution de code à distance (RCE) sans authentification, évaluée à 9,8 selon le score CVSS 3.0. Le problème vient du fait que la couche /api peut s’appuyer sur l’en-tête HTTP Host, contrôlé par le client, pour décider qu’une requête est « locale ». Or cet en-tête n’est pas une preuve d’identité. 1924

La gravité réelle dépend toutefois de la configuration. La commande Web documentée par DeepSeek démarre par défaut l’interface sur 127.0.0.1:3080, une adresse de bouclage qui limite fortement l’accès direct depuis le réseau. La situation devient nettement plus dangereuse lorsque le service est lié à une interface non locale ou rendu accessible par Docker, un proxy inverse, un tunnel, un VPN, un réseau local ou un ingress. 1118

Le contournement par l’en-tête Host

Le mécanisme concerné tente de distinguer les requêtes locales des requêtes distantes grâce aux informations présentes dans la requête HTTP. Mais la valeur de Host est fournie par le demandeur et peut être falsifiée. Un attaquant capable d’atteindre le service peut donc envoyer une valeur ressemblant à celle d’un accès local et amener la couche /api à considérer la requête comme fiable. Les rapports décrivent ce mécanisme comme un contournement de la limite de confiance fondée sur l’accès via la boucle locale. 1924

À un niveau général, la chaîne d’attaque rapportée est la suivante :

1. Atteindre une interface Web ou d’administration DSH exposée.
2. Envoyer une requête avec un en-tête Host forgé, présentant une valeur locale.
3. Contourner la restriction /api censée protéger les opérations internes.
4. Appeler des fonctions RPC normalement réservées.
5. Enregistrer ou utiliser une route vers un fournisseur de modèles contrôlé par l’attaquant.
6. Exploiter les capacités de l’agent DSH pour exécuter des commandes sur l’hôte. 1920

Ce n’est donc pas un simple défaut de routage ou de divulgation d’informations. Le contournement donne accès à des fonctionnalités conçues pour piloter un agent IA doté de capacités d’action sur le système.

Pourquoi cette faille peut déboucher sur une RCE

DeepSeek présente Harness comme un logiciel expérimental en préversion pour développeurs, qui n’a pas fait l’objet d’un audit de sécurité. Sa notice de sécurité avertit que le projet peut exécuter du code et des commandes générés par un modèle, ainsi qu’accéder aux fichiers, processus, identifiants et ressources réseau mis à sa disposition. 4

Le sous-système LLM permet également d’enregistrer des fournisseurs et de découvrir des modèles, notamment via l’opération distante discoverModels. 23 Dans la chaîne d’exploitation décrite par les sources, un fournisseur contrôlé par l’attaquant peut servir à fournir l’entrée nécessaire pour atteindre les capacités d’exécution de commandes de l’agent. 19

Une exploitation réussie ne donnerait pas automatiquement les droits root. Les commandes seraient exécutées avec les privilèges du processus qui fait tourner DSH. Ces privilèges peuvent néanmoins suffire à :

• lire ou modifier les fichiers accessibles au compte de service ;
• récupérer des identifiants, des clés d’API ou d’autres secrets disponibles ;
• lancer des processus et modifier des données applicatives ;
• établir une persistance ;
• effectuer des connexions sortantes ou explorer des ressources accessibles sur le réseau.

L’impact final dépend de l’environnement. Un conteneur privilégié, un socket Docker monté, des droits excessifs sur le système de fichiers ou des identifiants cloud accessibles peuvent aggraver fortement la situation. Les éléments fournis ne permettent toutefois pas d’affirmer que chaque installation mènerait automatiquement à une prise de contrôle complète de l’hôte.

Quelles configurations sont les plus exposées ?

Les équipes doivent examiner en priorité les déploiements suivants :

• DSH lié à 0.0.0.0 ou à une autre adresse non locale ;
• port 3080 publié par Docker ou un autre runtime de conteneurs au-delà de la machine ;
• proxy inverse transférant l’API d’administration vers Internet ou un réseau local non fiable ;
• tunnel, VPN ou ingress rendant le service accessible à des utilisateurs qui ne sont pas authentifiés de manière robuste ;
• proxy acceptant des valeurs Host arbitraires ou les transmettant telles quelles au service en amont.

Le fait qu’un service soit qualifié d’« interne » ne constitue pas, à lui seul, un contrôle d’autorisation. Tout acteur capable d’atteindre le point d’accès et d’influencer les en-têtes concernés peut tenter le contournement.

PoC public, statut CVE et exploitation observée

Plusieurs rapports indiquent que des éléments techniques ou une preuve de concept (PoC) concernant QVD-2026-57410 sont publics. 192027 Cette disponibilité réduit le délai de réaction nécessaire, mais elle ne constitue pas une preuve qu’une installation donnée a été compromise.

Les informations fournies ne font état d’aucune exploitation observée dans la nature, ni d’un lien établi avec un acteur malveillant ou une campagne connue au moment de la divulgation. 1924 Il s’agit d’un état des observations à cette date, et non d’une garantie de sécurité. Les instances exposées doivent malgré tout être vérifiées : requêtes /api inhabituelles, enregistrements inattendus de fournisseurs, nouveaux processus et connexions sortantes anormales sont notamment à rechercher.

QVD-2026-57410 est un identifiant QVD, et non un identifiant CVE. Le numéro similaire CVE-2026-57410 correspond à une vulnérabilité sans rapport dans le plugin MailerPress, selon la fiche du NVD. 17

Mesures recommandées aux opérateurs

1. Supprimer d’abord l’exposition réseau

Cessez de publier l’interface d’administration et l’API DSH sur Internet. Liez le service à l’interface de bouclage ou à un réseau de gestion dédié. Si un accès distant est nécessaire, utilisez un VPN contrôlé ou un bastion.

2. Restreindre l’accès à chaque niveau

Appliquez des règles de pare-feu, de groupes de sécurité cloud, de réseau de conteneurs et de proxy inverse n’autorisant que des sources explicitement approuvées. Ne considérez pas un routage interne ou un en-tête « local » comme une preuve d’identité.

3. Valider et réécrire les en-têtes du proxy

Au niveau du proxy en frontal, rejetez les valeurs Host inattendues. Lorsqu’un relais est indispensable, remplacez l’en-tête Host transmis au service amont par une valeur fixe et connue, au lieu de reprendre aveuglément celle fournie par le client. Les en-têtes d’adresse IP transférée ne doivent être considérés comme fiables que lorsqu’ils proviennent d’un proxy contrôlé.

4. Ajouter une authentification indépendante de Host

Protégez les fonctions d’administration et les opérations RPC internes par une véritable authentification et une autorisation adaptée : passerelle fortement authentifiée, certificats mutuels (mTLS) et contrôles d’accès par opération, par exemple. La validation de Host peut contribuer au routage, mais ne doit jamais constituer l’unique contrôle d’identité.

5. Réduire les risques liés à la découverte des fournisseurs

Désactivez ou restreignez llm.discoverModels lorsqu’il n’est pas nécessaire. Si la découverte de modèles est requise, autorisez uniquement les endpoints approuvés et imposez des règles de sortie réseau. Bloquer l’accès aux ressources internes sensibles et aux endpoints de métadonnées cloud peut limiter l’impact d’un abus de cette fonctionnalité comme primitive de requête côté serveur. La documentation LLM de DSH confirme que l’enregistrement des fournisseurs et la découverte des modèles font partie des capacités exposées. 23

6. Vérifier le correctif auprès de DeepSeek

Les sources fournies identifient la version 0.1.1-rc.2 comme concernée et montrent une activité de publication ultérieure, mais elles n’établissent pas qu’une version précise corrige cette vulnérabilité. Consultez les notes de version et les avis de sécurité actuels de DeepSeek avant de considérer une mise à niveau comme suffisante. La propre notice du projet continue de présenter Harness comme expérimental et non adapté à la production. 410

7. Rechercher une compromission et renouveler les secrets

Examinez les journaux du proxy inverse et de DSH à la recherche de requêtes /api anormales, de valeurs Host locales forgées, d’enregistrements inattendus de fournisseurs, de lancements de processus, de modifications de fichiers et de connexions sortantes inhabituelles. Faites tourner les identifiants accessibles au processus DSH. En cas d’indice d’exécution de commandes ou de persistance, isolez puis reconstruisez l’hôte ou le conteneur concerné au lieu de supposer qu’un simple redémarrage a supprimé l’intrusion.