Détournement d'agent en local : attaques WebSocket cross-origin sur les agents de code IA

Ce qui s’est passé

Le 7 mai 2026, Oasis Security a divulgué CVE-2026-44211 (CVSS 9.7), une vulnérabilité de détournement WebSocket cross-origin dans l’assistant de code IA Cline. La faille réside dans le paquet npm kanban livré avec le CLI Cline : ce paquet ouvre un serveur WebSocket sur 127.0.0.1:3484 pour relier l’interface de gestion locale aux sessions de l’agent IA en cours, et il le fait sans valider l’en-tête Origin et sans le moindre jeton d’authentification.

N’importe quelle page web chargée dans le navigateur du développeur peut ouvrir un WebSocket vers ce point d’entrée local et dialoguer avec l’agent. La vulnérabilité a fait l’objet d’une divulgation responsable et a été corrigée dans Cline 0.1.66. Les développeurs sur une version antérieure doivent mettre à jour sans délai.

Comment fonctionne cette classe d’attaque

Le bug est intéressant moins pour ses spécificités que pour le schéma structurel qu’il révèle. Les navigateurs appliquent CORS à fetch() et à XMLHttpRequest, mais les WebSockets échappent à la politique de même origine : n’importe quelle origine peut appeler new WebSocket("ws://127.0.0.1:3484"), et le navigateur laissera le handshake aboutir. C’est au serveur d’inspecter l’en-tête Origin et de refuser tout ce qui ne vient pas de sa propre interface. Le serveur de Cline ne le faisait pas.

Le serveur kanban de Cline exposait trois canaux WebSocket, chacun cassant un invariant différent :

1. Un canal de lecture qui, dès la connexion, envoyait à l’attaquant un instantané du workspace : chemins de fichiers, titres de tâches, branche git, historique de conversation avec l’agent.
2. Un canal d’entrée terminal qui écrivait directement dans le buffer de prompt de l’agent actif. Une page hostile injecte une instruction — par exemple, « lance ce script de build pour moi » — suivie d’un appui touche simulé. L’agent la traite comme une instruction utilisateur légitime et demande à son LLM sous-jacent quoi faire. Comme l’agent dispose déjà d’outils d’exécution shell, le résultat est une exécution de code à distance sur le poste du développeur.
3. Un canal de contrôle qui permettait de terminer les tâches d’agent actives, ouvrant la voie à un déni de service.

L’exploit tient en une ligne de script sur n’importe quelle page que visite le développeur — pas de XSS, pas d’extension installée, pas d’exploit natif. L’agent disposait déjà des privilèges ; il suffisait à l’attaquant de lui parler.

Pourquoi c’est important

C’est la même lethal trifecta — entrée non fiable, données sensibles, action externe — que Simon Willison a documentée en 2025 et que l’équipe AI Security de Meta a formalisée en Rule of Two en octobre 2025. Cline cumule les trois par conception : il s’exécute dans le workspace du développeur (données sensibles), il peut exécuter des commandes shell (action externe), et désormais, via le WebSocket non authentifié, il accepte de l’entrée non fiable depuis n’importe quel onglet de navigateur.

Le schéma est générique. Tout framework d’agent qui expose un plan de contrôle local — pour s’intégrer à un IDE, pour offrir un tableau de bord web, pour le débogage — est candidat au même bug. L’analyse Clinejection publiée ensuite par Snyk montre que la même classe d’agent est également exposée via des sorties GitHub Actions contaminées qui remontent dans son contexte. La CVE n’est qu’une instance d’une catégorie qui continuera à se manifester.

Défenses

Les mitigations sont architecturales, pas heuristiques. Pour les auteurs de frameworks d’agents :

1. Valider l’en-tête Origin sur chaque WebSocket upgrade. Rejeter tout ce qui n’est pas l’origine localhost attendue de l’UI. Cette seule mesure ferme le vecteur drive-by.
2. Générer un secret par session au démarrage du serveur, l’exiger sur chaque connexion WebSocket comme paramètre de requête ou sous-protocole, et ne jamais le journaliser.
3. Authentifier séparément le canal terminal. Le canal qui écrit dans le buffer de prompt de l’agent constitue, de fait, la surface la plus privilégiée du framework. Le traiter comme tel.
4. Lier le serveur à un socket Unix (ou un named pipe Windows) plutôt qu’à un TCP 127.0.0.1 quand c’est possible — les sockets locales n’exposent pas de port TCP atteignable par un navigateur.
5. Appliquer la Rule of Two. Si l’agent doit accepter de l’entrée non fiable, abandonner l’action externe ou les données sensibles pour cette session.

Pour les développeurs qui font tourner un agent de code IA :

• Mettez Cline à jour en 0.1.66 ou supérieur. Auditez tout autre agent qui ouvre un port local — extensions VS Code, variantes d’Aider, gateways MCP maison — pour vérifier la validation d’Origin et l’authentification.
• N’exécutez pas de tâche d’agent active pendant que vous naviguez sur du contenu web arbitraire. Traitez le terminal de l’agent comme un shell privilégié, parce que c’est ce que c’est.
• Surveillez les connexions sortantes de votre poste de développement. Un détournement drive-by pivote en général vers l’extérieur en quelques secondes.

Statut

Composant	CVE	CVSS	Divulgation	Corrigé dans
Cline (kanban npm)	CVE-2026-44211	9.7	2026-05-07	Cline 0.1.66

La leçon de fond : un port localhost est une surface d’attaque publique dès lors qu’un navigateur tourne sur la même machine. Les frameworks d’agents, héritiers de la culture outils-développeurs, redécouvrent encore ce que la communauté WebSec sait depuis dix ans. Tant que ce transfert de savoir n’est pas effectif, attendez-vous à d’autres CVE de détournement d’agent cross-origin tout au long de 2026.