AutoJack: Malicious Webpage Triggers RCE via AutoGen Studio MCP WebSocket — AI Browsing Agents Turn Localhost Trust Into Attack Surface

Microsoft disclosed AutoJack: three chained weaknesses in AutoGen Studio let a malicious webpage render RCE on the host developer machine via the local MCP WebSocket. Patched before PyPI release.

AutoGen Studio (Microsoft)Tool execution / MCPRemote code execution via MCP WebSocket — chained localhost trust bypass, missing endpoint authentication, and unsafe parameter handlingDeveloper workstations running AutoGen Studio from source with the MCP WebSocket plugin active, where a local AI browsing agent can be induced to load attacker-controlled web content

What happened

Attacker hosts a malicious webpage containing JavaScript that opens a WebSocket to ws://localhost:8081/api/mcp/ws/?server_params= with base64-encoded StdioServerParams naming an arbitrary executable (e.g. calc.exe or a reverse shell). Any local AI browsing agent induced to visit this page — via planted link, prompt injection into browsed content, or social engineering — triggers process execution on the developer's host machine under their own account credentials, with no further interaction required.

Why it matters

Arbitrary code execution on the developer's local machine with their own account privileges. Demonstrated payload: Windows Calculator launch (Calc.exe). Weaponized payload: any PowerShell, Bash, or executable reachable on the host. From initial foothold, attacker can exfiltrate credentials, cloud API keys, SSH keys, or plant persistent backdoors — pivoting from the developer workstation to production infrastructure, CI runners, and internal networks.

Missing authorization check

The MCP WebSocket must not accept invocations from content rendered by browsing agents without explicit per-command authorization via an independent channel. Localhost trust cannot substitute for authentication when the localhost caller is a remotely-controlled browsing context. Process-spawning parameters must be server-side bound, not caller-supplied — the MCP handler must never accept execution parameters directly from the WebSocket payload.

Would PP block it?

AutoJack's attack chain succeeds because the MCP endpoint accepts tool invocations from any caller who can reach it over localhost. PP breaks this by requiring that consequential tool calls — process spawning, shell execution, file writes — carry a receipt signed by an authority channel that is external to the agent's own execution context. A browsing agent rendering a malicious page cannot access PP's signing infrastructure, so even if the agent's MCP handler were fully compromised, the process-spawn would fail the receipt check before the OS ever saw the command. PP's enforcement is out-of-band: owning the agent runtime does not give you the signing key.

Incident analysis

Timeline and technical read

Timeline

2026-06-18
Microsoft Security Research publishes AutoJack disclosure on the Microsoft Security Blog. Three chained weaknesses described: localhost origin allowlist bypass via browsing agent, missing authentication on /api/mcp/* routes, unsafe base64-decoded server_params passed to process spawning. Patched in commit b047730 before the affected code reached a published PyPI release.
2026-06-18
Bleeping Computer, The Hacker News, CSO Online, and TechRadar cover the disclosure. Microsoft confirms autogenstudio 0.4.2.2 on PyPI is unaffected; exposure was limited to developers running dev builds from the main branch during the pre-release window.
2026-06-18
Microsoft notes the AutoJack pattern — localhost trust + missing MCP auth + agent-as-browser — is not specific to AutoGen Studio. Similar structures were confirmed in Semantic Kernel (CVE-2026-26030, CVE-2026-25592). Microsoft expects the attack surface class to recur across agent frameworks that host local MCP servers while also browsing the web.
2026-07-13
AutoJack resurfaces in July 2026 security roundups as a canonical example of AI browsing agent attack surface. PointGuard AI Security Incident Tracker, CSA Labs, and CybersecurityNews include it in broader MCP security analyses.

Technical breakdown

Weakness 1 — Origin allowlist bypass: AutoGen Studio's MCP WebSocket allowed connections from http://127.0.0.1 and http://localhost to prevent cross-site WebSocket hijacking. A browsing agent running locally inherits this localhost identity — any page it renders gets localhost privileges for WebSocket origin checks, making the allowlist meaningless for agent-rendered content.
Weakness 2 — Missing authentication: AutoGen Studio's authentication middleware explicitly excluded /api/mcp/* paths, assuming the WebSocket handler would enforce its own access control. The MCP handler implemented no such check, creating a completely open endpoint regardless of which authentication mode was configured (GitHub, MSAL, Firebase).
Weakness 3 — Unsafe parameter handling: the MCP WebSocket accepted a server_params query parameter, base64-decoded it into StdioServerParams, and passed the executable name and arguments directly to process-spawning code with no allowlisting. This gave any caller who reached the endpoint arbitrary process execution.
The three weaknesses form an unbounded chain: browsing agent → localhost trust → unauthenticated MCP endpoint → arbitrary process spawn. An attacker who can induce the browsing agent to load one page fully controls the chain. Attack vectors include planted hyperlinks in agent-browsed content, prompt injection via page text, or direct social engineering of the developer.
Microsoft demoed the exploit launching Windows Calculator. Weaponization requires substituting calc.exe with a reverse shell, credential harvester, or SSH backdoor installer — all standard payloads that execute under the developer's full account privileges.

Authorization boundary

Where the authorization boundary should have been

This incident is categorized as Tool execution / MCP. The relevant Permission Protocol gate is Runtime Gate. The read is conditional: the block only applies where the real action boundary is routed through a gate.

If enforced at: Runtime Gate — any MCP tool call that spawns a process or executes code requires a PP receipt signed by an authority channel external to the calling agent's execution context
Still needs: Browser sandboxing for local AI agents (preventing localhost WebSocket access from rendered content); MCP server authentication middleware coverage of all routes; build pipeline enforcement that catches missing auth middleware exclusions before release
Receipt required for: Every process-spawning and shell-execution MCP tool call — receipts must name the specific executable and argument list, signed by a channel that cannot be reached from the rendering context of a browsing agent

PP's Runtime Gate requires a signed receipt from an independent authority channel before any tool call that spawns a process or executes code. The AutoJack payload — a base64 server_params blob submitted via WebSocket from a browsing agent's JavaScript — cannot produce a PP receipt. The malicious page can compromise the agent session but cannot forge the authority channel that PP's enforcement layer requires.

Lessons for teams

Localhost origin allowlists provide no security boundary for local AI browsing agents — agents that render external content run external JavaScript with local network privileges. The security model that protects browser users from CSRF does not apply when the browser is itself an AI agent with localhost access.
MCP server authentication middleware must cover every route, including WebSocket upgrade paths. Explicit middleware exclusions for 'self-authenticating' handlers that never implement the check are a systemic failure mode — and one that compounds in agent frameworks where multiple plugins share a single server.
Process-spawning parameters must be server-side bound and cannot be trusted from caller payloads. Any MCP server that accepts executable names or arguments directly from WebSocket messages will be exploitable if the authentication boundary fails.
The AutoJack pattern — local agent + local MCP server + web browsing — is a structural attack surface class, not an implementation bug. Every agent framework that combines local service hosting with web-browsing capability needs an independent authority mechanism for consequential tool calls.
Pre-release exposure windows for developer tooling carry real risk even when published packages are clean. Developers building from source are exposed to vulnerabilities that the PyPI version never contains — and they are typically the highest-privilege targets (CI access, production credentials, SSH keys).

Related incidents and controls

High2026-05-07

TrustFall Coding Agent Security Flaw Enables One-Click RCE

Critical2026-05-08

Cline AI agent CVE-2026-44211 allows unauthenticated WebSocket hijack and RCE

Critical2026-05-07

Prompt injection in Microsoft Semantic Kernel enables remote code execution via AI model-controlled eval()

Critical2026-06-08

Agentjacking: Attackers inject malicious instructions into fake Sentry errors via public DSN, hijacking Claude Code, Cursor, and Codex with 85% success rate across 2,388 organizations

Runtime Gate Why governance must be external

Start small

Put the relevant gate at this action boundary.

This incident maps to Runtime Gate. Start with the boundary that controls the actual action, then require a signed receipt before execution.

Replay this incident with a signer in the loop