AutoJack : un agent navigateur transforme une page web en RCE sur l'hôte

De quoi s’agit-il ?

Le 18 juin 2026, la Microsoft Defender Security Research Team a publié AutoJack, une chaîne d’exploitation visant AutoGen Studio — l’interface de prototypage open source du framework multi-agents AutoGen de Microsoft. Une simple page web malveillante, une fois rendue par un agent navigateur local, peut atteindre un WebSocket Model Context Protocol (MCP) local et lancer des processus arbitraires sur l’hôte. Microsoft a baptisé la technique AutoJack parce qu’elle « détourne » l’agent et en fait le véhicule de livraison final de l’attaquant, franchissant la frontière de confiance localhost sur laquelle d’innombrables outils de développement reposent silencieusement. La faille a été signalée au MSRC et corrigée dans le commit b047730 avant toute publication — il s’agit donc d’un schéma documenté, pas d’un 0-day actif.

Comment ça fonctionne

AutoJack compose trois faiblesses indépendantes de la surface WebSocket MCP d’AutoGen Studio. Aucune n’est exotique isolément ; chaînées, elles produisent une exécution de code sur l’hôte.

D’abord, une liste d’origines autorisées que l’agent lui-même contourne (CWE-1385, absence de validation d’origine pour les WebSockets). Le WebSocket MCP n’accepte que les connexions dont l’Origin est http://127.0.0.1 ou http://localhost. Cela bloque correctement un humain pointant un navigateur vers evil.example. Mais cela ne bloque pas le JavaScript rendu par un navigateur headless possédé par un agent sur la même machine — un MultimodalWebSurfer, un surfer basé sur Playwright, ou tout outil d’exécution de code. Tout ce que l’agent charge hérite de l’identité loopback.

Ensuite, l’authentification est désactivée pour les chemins MCP (CWE-306, absence d’authentification d’une fonction critique). Le middleware d’authentification d’AutoGen Studio ignorait explicitement /api/mcp/* et /api/ws/*, supposant que ces handlers vérifieraient eux-mêmes les jetons. Le handler du WebSocket MCP ne l’a jamais fait : il acceptait donc les connexions sans authentification, quel que soit le mode configuré.

Enfin, server_params issu de l’URL est la ligne de commande (CWE-78, injection de commande OS). Le point de terminaison lisait un paramètre de requête server_params, décodait en base64 un blob JSON vers StdioServerParams, puis passait command + args directement à stdio_client(). Sans liste blanche d’exécutables, calc.exe, powershell.exe -enc [REDACTED] ou bash -c [REDACTED] étaient tous acceptés comme « serveurs MCP ».

La chaîne complète : l’utilisateur confie à un agent « résume cette URL » d’apparence anodine une page d’attaquant ; le navigateur headless de l’agent la rend ; le JavaScript de la page ouvre ws://localhost:8081/api/mcp/ws/<id>?server_params=[REDACTED] ; comme la requête provient de la machine, le contrôle d’origine passe ; comme le middleware court-circuite les chemins MCP, aucun jeton n’est requis ; et AutoGen Studio décode la charge et lance la commande de l’attaquant sous le compte du développeur. C’est un problème classique de député confus (confused deputy) — aucune charge utile n’est reproduite ici, car la leçon est structurelle, pas une recette.

Pourquoi c’est important

L’enjeu n’est pas AutoGen Studio en particulier — Microsoft précise que la route concernée n’a jamais été publiée sur PyPI, et le paquet actuel (autogenstudio 0.4.2.2) ne la contient pas. L’enjeu, c’est le schéma : dès qu’un agent sur votre poste peut à la fois naviguer sur du contenu non fiable et dialoguer avec des services locaux privilégiés, localhost cesse d’être une frontière de confiance. Le loopback a longtemps été considéré comme implicitement fiable — points de terminaison de debug, bases de données de dev, exécuteurs de code, sockets de contrôle MCP s’y attachent souvent sans authentification. Un agent navigateur local dissout cette hypothèse : le contenu externe pilote désormais un processus qui vit déjà dans la zone de confiance. C’est la même famille de risque structurel que la trifecta létale et le détournement d’agent localhost — l’agent est le pont entre l’entrée non fiable et la capacité privilégiée.

Défenses

Les mitigations sont concrètes et essentiellement architecturales :

• Ne jamais attacher de plan de contrôle sensible à localhost sans authentification. Sur loopback, les sockets de contrôle MCP, points de debug, exécuteurs de code et bases de dev sont une surface d’attaque pour tout agent présent sur la machine, et non un défaut sûr.
• Mettre en liste blanche les exécutables pouvant être lancés comme serveurs MCP plutôt que d’accepter command/args de n’importe quel appelant. Le correctif de Microsoft a déplacé les paramètres côté serveur : un POST séparé les stocke par UUID, et le handler WebSocket refuse les identifiants inconnus.
• Placer le plan de contrôle derrière un reverse proxy authentifié qui impose l’authentification sur tous les chemins, y compris WebSocket et /api/* — ne pas se fier aux seuls modes d’authentification du framework.
• Suivre la provenance / utiliser des boucliers anti-injection pour intercepter la phase de navigation initiale, lorsque le contenu de l’attaquant oriente d’abord l’agent vers une page malveillante.
• S’appuyer sur la détection comportementale EDR. La chaîne se termine par un processus parent Python ou Node qui engendre un processus enfant inattendu — exactement le motif que l’EDR est conçu pour signaler. Exécuter les builds d’agents expérimentaux dans des postes managés ou en bac à sable limite le rayon d’impact.

Statut

Élément	Détail
Divulgation	18 juin 2026 (Microsoft Defender Security Research Team)
Affecté	Route WebSocket MCP d’AutoGen Studio compilée depuis main durant la fenêtre pré-publication
Non affecté	Release PyPI autogenstudio 0.4.2.2 (route absente)
Correctif	Commit upstream b047730 ; main en version 0.7.2
Classe	CWE-1385 + CWE-306 + CWE-78 chaînées → RCE sur l’hôte