système : OPÉRATIONNEL
← retour à tous les hacks
AGENTS CRITICAL NEW

Le dashboard Hub de Cline : la boucle locale prise pour une authentification, encore

Un avis du 8 juillet 2026 montre que le dashboard Hub de Cline expose un WebSocket local sans vérification d'Origin et avec un secret partagé désactivé par défaut — la deuxième faille WebSocket cross-origin de Cline en deux mois.

2026-07-16 // 6 min affects: cline, ai-coding-agents, local-agent-servers, mcp

De quoi s’agit-il ?

Le 8 juillet 2026, le projet Cline a publié un avis de sécurité concernant son dashboard Hub — le serveur local lancé par la commande cline dashboard dans les versions antérieures à 3.0.30. Le dashboard expose un point d’accès WebSocket à /browser sur 127.0.0.1:8787 afin que l’interface web puisse dialoguer avec l’agent de bureau. Le défaut : le serveur ne vérifie jamais l’en-tête HTTP Origin lors du handshake WebSocket, et le secret partagé censé protéger ce canal n’est pas défini par défaut sur les liaisons locales. Conséquence : l’exécution de commandes arbitraires sur la machine d’un développeur, déclenchée par la simple visite d’une page web malveillante.

C’est la deuxième faille WebSocket cross-origin divulguée dans Cline en environ deux mois, après celle du serveur Kanban. La récurrence est le vrai sujet : la liaison sur la boucle locale continue d’être prise pour une frontière d’authentification, ce qu’elle n’est pas.

Comment ça marche

Les navigateurs autorisent librement les connexions WebSocket cross-origin. La same-origin policy qui bloque les lectures fetch inter-sites n’empêche pas une page hébergée sur evil.example d’ouvrir ws://127.0.0.1:8787/browser. C’est un comportement voulu de la plateforme web, et c’est précisément pourquoi un service local doit vérifier lui-même l’en-tête Origin.

Le dashboard Hub délègue cette décision à une fonction nommée isAuthorizedBrowserRequest(). Lorsque la variable d’environnement ROOM_SECRET n’est pas définie — le cas par défaut pour une liaison locale 127.0.0.1 — la fonction renvoie systématiquement vrai. Chaque connexion entrante est acceptée comme si elle provenait de l’onglet légitime du dashboard. L’attaquant envoie alors des trames desktopCommand qui lisent l’état de l’espace de travail et de la session, réécrivent la configuration des serveurs Model Context Protocol (MCP) et modifient les réglages de fournisseur et de modèle d’IA.

Le passage à l’exécution de code découle d’un second réglage par défaut : les sessions du dashboard s’exécutent avec autoApprove: true pour tous les outils. Dès qu’un fournisseur ou un modèle est configuré, une commande injectée s’exécute sans étape d’approbation humaine. Deux hypothèses « sûres par défaut » — la boucle locale est de confiance, les outils sont auto-approuvés — se combinent en un chemin complet vers l’exécution de code à distance.

Pourquoi c’est important

Les serveurs d’agents locaux deviennent un composant standard de la pile de développement assistée par IA, et chacun de ceux qui écoutent sur la boucle locale hérite exactement de cette exposition. Il suffit qu’un développeur ait le dashboard en cours d’exécution puis navigue normalement sur le web ; la page malveillante n’a besoin d’aucun identifiant ni accès préalable. Comme la portée passe d’une origine de navigateur au compte de bureau du développeur, le rayon d’impact inclut le code source, les identifiants cloud stockés comme clés de fournisseur, et tout ce que les outils de l’agent peuvent atteindre.

La divulgation s’inscrit dans une série de découvertes similaires visant les agents de codage en juillet 2026, dont le dénominateur commun est un service lié localement qui suppose que l’interface de boucle locale constitue une frontière de confiance. Elle ne l’est pas : n’importe quelle origine chargée par le navigateur peut lui envoyer du trafic.

Défenses

  • Passez à Cline 3.0.30 ou une version ultérieure. Le correctif ajoute une validation de l’hôte et de l’Origin via un nouveau contrôle isAuthorizedBrowserToDesktopRequest et restreint les hôtes acceptés à l’aide de isIP du module net de Node.
  • Définissez un ROOM_SECRET robuste avant de démarrer le dashboard si vous devez exécuter une version ancienne, afin que le contrôle d’autorisation impose un secret partagé au lieu de faire confiance à toute connexion (export ROOM_SECRET="$(openssl rand -hex 32)").
  • N’exécutez pas le dashboard en naviguant sur des sites non fiables sur le même hôte, et évitez de le laisser tourner sans surveillance.
  • Validez l’Origin sur chaque WebSocket local et considérez la boucle locale comme non fiable. Rejetez les handshakes dont l’origine ne correspond pas à l’UI locale attendue ; ne comptez pas sur la liaison 127.0.0.1 comme authentification.
  • Repensez l’auto-approbation généralisée. Les appels d’outils capables d’exécuter des commandes ne devraient pas être autoApprove: true par défaut ; conservez un contrôle humain pour les actions sensibles.
  • Renouvelez les clés d’API de fournisseur et les identifiants MCP configurés pendant l’exécution d’une version vulnérable, et surveillez les processus d’agent qui lancent des shells peu après une activité du navigateur.

Statut

ÉlémentValeur
RéférenceCVE-2026-59723 / GHSA-3cj3-hqcr-g934
ConcernéDashboard Hub de Cline, CLI/SDK/extension IDE avant v3.0.30
Cause racineAbsence de validation d’Origin + ROOM_SECRET non défini par défaut (CWE-346)
SévéritéCVSS 8.8 (élevée) ; EPSS ~0,14 % ; absente du CISA KEV
Corrigé dansCline CLI v3.0.30
Publié8 juillet 2026 (NVD)

Dates clés : 8 juillet 2026 — publication de l’avis et du NVD. Correctif livré dans Cline CLI v3.0.30. Problème antérieur lié : la faille WebSocket cross-origin du Kanban de Cline divulguée le mois précédent.

Sources