AutoJack : une seule page web suffit pour prendre le contrôle de votre machine via un agent IA

1. Confiance aveugle en localhost

Le WebSocket MCP acceptait tout le trafic provenant de l'interface de boucle locale (127.0.0.1) comme étant intrinsèquement fiable. Il ne vérifiait pas si la requête provenait réellement de l'agent légitime ou d'un contenu web contrôlé par l'attaquant que l'agent avait rendu . Comme l'agent lui-même s'exécute localement, toute page web chargée par l'agent pouvait envoyer des messages WebSocket que le service MCP traitait comme s'ils provenaient d'une source locale de confiance.

2. Absence d'authentification sur le point d'accès WebSocket

Le point d'accès WebSocket MCP n'exigeait aucune authentification, ni jeton de session, ni vérification d'origine. Tout processus local — ou tout script s'exécutant dans une page web rendue par l'agent — pouvait accéder au WebSocket et envoyer des commandes sans identifiants . Cela signifiait qu'il n'y avait aucun moyen pour le service de distinguer les appels d'outils légitimes de l'agent des instructions malveillantes injectées par la page web de l'attaquant.

3. Lancement de processus non sécurisé à partir des commandes d'outils

Le service MCP exécutait aveuglément les commandes d'outils reçues via le WebSocket. Il permettait la création arbitraire de processus sans sandboxing, sans vérification des capacités, et sans confirmation de l'utilisateur . Une fois que le contenu de l'attaquant atteignait le WebSocket, il pouvait ordonner au service d'exécuter n'importe quelle commande sur la machine hôte.

Combinées, ces trois faiblesses permettent à une page web d'ordonner au moteur de navigation de l'agent IA de se connecter au WebSocket MCP, d'envoyer des commandes d'outils conçues pour l'attaque, et d'exécuter du code arbitraire — tout cela sans que l'utilisateur n'ait à cliquer sur un second bouton .

Versions concernées et correctif appliqué

La vulnérabilité n'existait que dans la branche de développement d'AutoGen Studio, l'interface utilisateur de prototypage open source du framework multi-agents AutoGen de Microsoft . Elle n'a jamais été incluse dans une version PyPI d'AutoGen Studio ou d'AutoGen lui-même . Après que Microsoft a signalé le problème aux mainteneurs d'AutoGen via le Microsoft Security Response Center (MSRC), le correctif a été appliqué à la branche de développement . Les utilisateurs sont invités à mettre à jour leur version d'AutoGen Studio vers la dernière version pour bénéficier du correctif . Aucun numéro CVE n'a été rapporté pour ce problème dans les sources disponibles.

Implications plus larges pour la sécurité des agents IA

Au-delà de la vulnérabilité spécifique, Microsoft souligne qu'AutoJack démontre un risque architectural fondamental pour tout framework d'IA agentique qui combine navigation web et accès local aux outils . Le bac à sable du navigateur a été conçu pour isoler le contenu web du système d'exploitation. Mais un agent IA qui se trouve à l'intérieur de la frontière de confiance et agit sur le contenu rendu crée un pont entre le web ouvert et les opérations locales privilégiées .

Microsoft prévient que l'hypothèse traditionnelle consistant à traiter localhost comme une zone de confiance implicite n'est plus tenable lorsque des agents sont impliqués . L'entreprise recommande que les frameworks d'IA agentique adoptent :

• Une authentification explicite pour tous les points d'accès MCP, même ceux qui écoutent sur localhost
• Une validation de l'origine pour garantir que seul l'agent légitime peut envoyer des commandes
• Des contrôles d'accès basés sur les capacités qui limitent ce que chaque commande d'outil peut faire
• Un sandboxing des processus pour tout outil pouvant atteindre les ressources système

localhost était autrefois une frontière de sécurité. Avec les agents IA qui naviguent sur le web ouvert, il est devenu une surface d'attaque.