Security

AutoJack Exploit Chain Targeted AutoGen Studio's MCP WebSocket

Microsoft researchers disclosed a localhost trust boundary vulnerability in the AI agent framework's development branch—fixed before any public release.

Omega Editorial· June 19, 2026· 4 min read

Localhost becomes an attack surface when AI agents browse the web

Microsoft security researchers have disclosed a remote code execution vulnerability in AutoGen Studio, the prototyping interface for AutoGen's multi-agent AI framework. The exploit chain, dubbed AutoJack, allowed untrusted web content rendered by a browsing agent to reach a local Model Context Protocol (MCP) WebSocket and spawn arbitrary processes on the host machine.

The vulnerability was identified during development and fixed before any public release. Users who installed AutoGen Studio from the Python Package Index (PyPI) were never exposed to the affected code, according to Microsoft's security blog.

The attack worked by chaining three independent weaknesses: an origin allowlist that trusted localhost connections, authentication middleware that skipped MCP paths, and a WebSocket handler that accepted base64-encoded command parameters from URLs without validation. When an AutoGen agent with browsing capabilities rendered a malicious page, the JavaScript on that page could open a WebSocket to the local AutoGen Studio instance and execute arbitrary commands—including launching calc.exe, PowerShell scripts, or bash commands.

Why it matters

The AutoJack disclosure illustrates a fundamental security challenge for AI agent frameworks: when agents can both browse untrusted content and communicate with privileged local services, the localhost trust boundary collapses. This pattern will recur across the agent ecosystem as frameworks wire language models to browsers, code interpreters, and system tools. Developers building on agent platforms need to treat any tool parameter reachable from model output as attacker-controlled and authenticate all control-plane endpoints—even those bound to loopback addresses.

How the exploit chain worked

In a realistic attack scenario, a developer runs AutoGen Studio on the default port (8081) and builds an agent with web-browsing capabilities—such as a content summarizer using MultimodalWebSurfer. An attacker plants malicious JavaScript on a webpage, either on their own domain or via injection into a legitimate site's comment section. When the agent navigates to that page, the JavaScript opens a WebSocket connection to ws://localhost:8081/api/mcp/ws/ with a base64-encoded payload in the query string.

Because the headless browser is running on the same machine, the Origin header satisfies the allowlist. Because the authentication middleware explicitly skipped /api/mcp/* paths, no token is required. The WebSocket handler then decodes the payload, extracts command and arguments, and passes them directly to stdio_client() to spawn an MCP "server" process—which could be any executable.

Microsoft's proof-of-concept demonstrated the full chain on a single workstation: within seconds of the agent rendering the attacker's page, calc.exe launched under the developer's account, spawned by the AutoGen Studio process.

Fixes applied before release

Maintainers hardened the main branch in commit b047730 with two key changes. First, they moved server parameters server-side: a separate POST endpoint now stores parameters keyed by UUID, and the WebSocket handler refuses connections with unknown session IDs. Second, they removed /api/mcp from the authentication skip-list, forcing MCP routes through the normal auth path.

The affected MCP WebSocket surface never appeared in any PyPI release. The current published version (0.4.2.2) does not include the vulnerable route file, and a recursive search of the package confirms no references to StdioServerParams or /api/mcp.

Guidance for agent developers

Microsoft recommends deploying AutoGen Studio strictly as a developer prototype in isolated environments, not as an internet-exposed service. Developers building agent applications on any framework should refuse to bind sensitive control planes to localhost without authentication, allowlist which executables may be invoked as external tools, and separate the agent's browsing identity from the developer's OS account—ideally using containers or dedicated user profiles.

For detection, Microsoft Defender and Azure AI Content Safety Prompt Shields can catch indirect prompt injection attempts that steer agents toward malicious pages, providing an early interception point before client-side JavaScript executes.

The research was first reported by Microsoft's AI security team on the company's security blog.

#autogen#ai-agent-security#remote-code-execution#model-context-protocol#localhost-vulnerability#prompt-injection

This is an original analysis by the Omega editorial team. Source reporting: AI Watch.

Want systems like this working for your business?

Book a Call

More in Security

Security· 3 min read

AI-Generated Video Falsely Shows Iranian Troops Downing US Helicopter

A widely shared clip depicting the June 2026 Apache downing contains visual errors and tested positive for fabrication by detection tools.

Via AI Watch · Jun 19, 2026
Security· 3 min read

Cisco to Acquire WideField Security for AI Agent Governance

The deal extends Splunk's autonomous security operations with identity and session intelligence designed for machine-speed threats from AI agents and non-human identities.

Via AI Watch · Jun 19, 2026
Security· 3 min read

White House Orders Anthropic to Restrict AI After Jailbreak Reports

Simple prompt tricks allow users to bypass chatbot safety controls, revealing vulnerabilities in even the most advanced models.

Via AI Watch · Jun 18, 2026