A single malicious webpage is all it takes to turn an AI agent into an unwitting attack vector against a developer’s own machine. Researchers at Microsoft Defender Security Research have documented a multi-stage exploitation chain they call AutoJack. The chain enabled remote code execution on any developer machine running AutoGen Studio, provided the AI agent could be directed to visit an attacker-controlled page.
What Is AutoGen Studio?
AutoGen Studio is a rapid-prototyping interface built on top of the AutoGen framework. It allows developers to assemble and test multi-agent AI systems quickly, without writing extensive boilerplate code. Its convenience, however, introduced a combination of weaknesses that the AutoJack chain exploited in sequence.
How the AutoJack Attack Chain Worked
Step One The Agent Browsed External Pages
The first prerequisite was straightforward. AutoGen Studio permitted agents to visit external websites as part of their assigned tasks. An attacker simply needed to lure an agent to a page they controlled, whether through a crafted task prompt or an indirect prompt injection embedded in content the agent was asked to summarize.
Step Two Localhost Trust Was Bypassed
Normally, browser same-origin policies prevent a remote website from contacting services bound to localhost or 127.0.0.1. However, the AI agent itself was running on the developer’s machine. Because the agent made the request locally, the attacker’s page could communicate with the local AutoGen Studio management interface as though it were a trusted local client.
Step Three MCP Routes Skipped Authentication
The second weak link lay in how AutoGen Studio handled authentication. Paths matching /api/mcp/* and /api/ws/* were excluded from the application’s shared authentication middleware. The assumption was that the individual handler for those routes would enforce its own access checks. In practice, the MCP WebSocket handler performed no such verification. Consequently, an incoming connection was accepted without any token, even when the rest of the application had authentication fully enabled.
Step Four Arbitrary Command Execution via server_params
The most dangerous flaw resided in the MCP WebSocket endpoint itself. It accepted a server_params value directly from the URL query string, decoded it from Base64, deserialized it into a StdioServerParams configuration object, and passed it along as a command to launch an MCP server process. There was no allowlist restricting which executables could be specified. An attacker could therefore substitute a legitimate MCP server binary with any arbitrary executable including calc.exe, PowerShell, or bash accompanied by whatever arguments they chose.
The Full Attack Flow
To demonstrate the vulnerability, a researcher configured AutoGen Studio to run on local port 8081 and asked an agent to briefly summarize the contents of a webpage. The agent navigated to the attacker-controlled site. An embedded script on that page opened a WebSocket connection back to the local AutoGen Studio instance, transmitted the crafted server_params payload, and caused the application to execute an arbitrary command under the developer’s user account. No additional interaction from the victim was required.
Microsoft’s Response and Fixes
Microsoft reported the findings to the Microsoft Security Response Center. Developers subsequently hardened the codebase in the main AutoGen branch. The WebSocket handler no longer accepts server_params from the URL query string. Parameters are now bound server-side through a dedicated API request tied to a session identifier. Additionally, MCP routes are now subject to the same authentication middleware as all other endpoints in the application.
Who Was Actually Affected?
Microsoft clarified that the vulnerable code was never published to the Python Package Index. Developers who installed AutoGen Studio via pip install were not exposed to this specific attack chain. The risk was confined to those who built AutoGen Studio directly from the main GitHub branch during the window between when MCP support was merged and when the vulnerability was patched.
A Broader Warning for AI Agent Developers
The AutoJack chain illustrates a broader security principle that grows more pressing as AI agents become more capable. When an agent can browse untrusted web content and simultaneously access privileged local services, the localhost boundary no longer provides meaningful protection.
Microsoft’s researchers offer clear guidance for anyone building similar systems. First, require authentication on every management interface without exception. Second, restrict agents from spawning arbitrary external processes. Third, isolate agents from the developer’s primary user account. Finally, run AI prototypes inside containers, virtual machines, or dedicated sandboxes to limit the blast radius of any successful exploitation.
Support Our Threat Intelligence
If you find our technology report and cybersecurity news helpful, consider supporting our work.
Buy Me a Coffee
PayPal
