A single webpage can hijack a browsing AI agent and run code on the host, Microsoft finds

A single malicious webpage rendered by a browsing AI agent can hijack that agent and run arbitrary code on the developer's host. Microsoft researchers call the new pattern AutoJack. PyPI users are not exposed, but the chain shows why "local" no longer means "safe" in agent stacks.

What AutoJack actually is

Microsoft's Defender Security Research team published the details on June 18, 2026, in a blog post titled "AutoJack: How a single page can RCE the host running your AI agent." The team said it found the chain in AutoGen Studio, a user interface Microsoft Research ships on top of its open source AutoGen multi-agent framework. The chain combined three separate weaknesses in the studio's local WebSocket control plane and chained them into a remote code execution primitive. The team named the technique AutoJack because the attack effectively carjacks a browsing agent and uses it as a confused deputy to cross the localhost trust boundary most developer tools still assume.

The big lesson is not about AutoGen Studio. The vulnerable code was found in a development branch and fixed before the affected MCP WebSocket surface ever reached a PyPI release, so no one running `pip install autogenstudio` today is exposed to the specific chain. The lesson is about a pattern. When an agent on a developer laptop can browse the open web and also talk to a privileged local service, the loopback interface stops being a trust boundary, and any unauthenticated control plane listening on it becomes a delivery channel for arbitrary code execution.

The same Microsoft team has been working through this category of bugs for a while. Earlier in the series they covered RCE primitives in Microsoft Semantic Kernel. AutoJack moves one layer up the stack to the developer-facing prototype surface where most people are actually wiring up their first agents, and shows the same dynamic: the agent capabilities that make a tool useful for quick experimentation are exactly the ones that turn it into a delivery vehicle for malicious code if it ships without authentication, allowlists, and identity isolation.

The chain reads like a textbook case of three small decisions that look reasonable in isolation but combine into a full takeover. The first weakness is an origin allowlist on the studio's MCP WebSocket endpoint that only accepts connections whose Origin header is `127.0.0.1` or `localhost`. That is the right control for a human user opening a browser tab to a malicious website. A browser pointed at `evil.com` will send the wrong origin, the check will fail, and the connection will be refused. The problem is that an agent running on the same machine, whether it uses AutoGen's `MultimodalWebSurfer`, `fetch_webpage_tool`, a Playwright backed surfer, or a code execution tool that runs `requests` and `websockets`, is itself a process on the workstation. Any JavaScript it renders inherits the localhost identity. The origin of the WebSocket call the page then makes satisfies the allowlist, and the loopback check is defeated by the very thing it was designed to protect.

The second weakness is the authentication middleware. AutoGen Studio supports a few authentication modes (none, github, msal, firebase) and routes all of them through a single AuthMiddleware that runs ahead of FastAPI route dispatch. The middleware contains an early return for WebSocket style paths. The intent was reasonable: ASGI middlewares cannot meaningfully gate WebSocket handshakes the same way they gate HTTP requests, so the design called for the WebSocket handler to enforce authentication itself at accept time. The MCP route never picked up that responsibility. Microsoft mapped it out in a table. None: REST not protected, MCP not protected. GitHub: REST protected, MCP not protected. MSAL: REST protected, MCP not protected. Firebase: REST protected, MCP not protected. Turning on auth in `config.yaml` does not close this hole on its own.

The third weakness is the most directly dangerous. The MCP WebSocket route accepted a `server_params` query parameter, base64 decoded it, JSON parsed the result into a `StdioServerParams` object, and passed the command and arguments directly to `stdio_client`. There was no allowlist on which executables could be invoked, so the same plumbing that is meant to spawn a legitimate MCP speaking binary would happily launch `calc.exe`, `powershell.exe -enc <base64>`, or `bash -c '<anything>'`. A minimal payload looks like `{ "type": "StdioServerParams", "command": "calc.exe", "args": [], "env": { "pwned": "true" } }`. Base64 encoded into a query string, the reach out URL is `ws://localhost:8081/api/mcp/ws/<id>?server_params=<base64>`. Combined with the first two weaknesses, all an attacker needs is for the agent to render a page that opens that URL.

Microsoft classified the chain against three CWE entries that show up again and again in agent security work. CWE-1385, missing origin validation in WebSockets. CWE-306, missing authentication for a critical function. CWE-78, improper neutralization of special elements used in an OS command. The pattern matters more than any single bug, because the same shape is starting to show up in other prototypes, demos, and tools where the same instinct to make the local experience feel friction free has outpaced the work to authenticate and isolate it.

The proof of concept, the fix, and the mitigations

To validate the end to end chain, the team wrote two small harnesses. The first, `malicious_web_server.py`, served a page at an attacker-controlled domain whose only meaningful content was a script tag that opened the WebSocket above with a base64 payload designed to run `calc.exe`. The second, `web_summarizer_app.py`, was a small Web Content Summarizer agent wrapped in a Flask UI. The app took a URL from the user and handed it to a `MultimodalWebSurfer` agent with the prompt "Browse this URL and summarize its content." It is, in other words, a fully functioning AutoGen agent that any developer could build on top of the framework. The Flask page is just the interface.

The end to end flow has the developer building an AutoGen agent such as a Web Page Summarizer, or any agent with browsing capabilities, that runs on the same machine as AutoGen Studio. An attacker plants a malicious comment on a legitimate news site, or a user pastes an attacker controlled URL into the summarizer, or the agent encounters the URL through a prompt injection in earlier content. The agent's browsing tool navigates the headless browser to the attacker page. The page's JavaScript opens the WebSocket URL. Because the browser is on the same machine, the origin is acceptable. Because the auth middleware short circuits `/api/mcp/*`, no token is required. AutoGen Studio decodes the payload and runs `calc.exe` under the developer's account.

In the published demo, `calc.exe` pops on the developer's desktop within seconds of the agent rendering the page. The parent process is the AutoGen Studio process, not the browser and not the agent's headless Chromium, which is what makes the chain invisible to most web focused defenses. In a real world deployment, the same primitive could execute any attacker chosen command on whatever host is running the studio, scoped only by the privileges of that process.

The exposure window was narrow. The vulnerable code was on a development branch that included MCP support and was never shipped through the current PyPI release. Anyone who installed AutoGen Studio from PyPI was not exposed. The risk applied to developers who built from source during the window between the MCP plugin landing and the hardening commit. The team confirmed this by downloading `autogenstudio 0.4.2.2` and inspecting it directly. The package does not include `autogenstudio/web/routes/mcp.py`, the FastAPI app in `app.py` does not mount an `/api/mcp` router, and a recursive search across all 55 Python files found no matches for `StdioServerParams` or `/api/mcp`. Today, `pip install autogenstudio` gets you a build that does not contain the attack surface at all.

The Microsoft Security Response Center coordinated the fix with the AutoGen Studio maintainers. The hardening landed in commit `b047730` on the main branch and `pyproject.toml` is at `0.7.2`. Three changes close the specific chain. The WebSocket handler no longer reads `server_params` from the URL. A separate `POST /api/mcp/ws/connect` route stores the parameters server side in `pending_session_params`, keyed by a UUID. The WebSocket handler pops the entry by session ID and refuses unknown IDs with close code 4004. The middleware skip list no longer includes `/api/mcp` and only includes `/api/ws` and `/api/maker`. MCP routes now flow through the normal auth path.

The broader mitigation guidance is where the lasting value sits. Microsoft recommends treating any tool parameter reachable from model output as attacker controlled. Refuse to bind sensitive control planes (debug endpoints, MCP control sockets, code executors, dev databases) to localhost without authentication, because loopback is an attack surface for any agent on that machine. Allowlist which executables may be invoked as MCP servers, instead of accepting command and args from any caller. Separate the agent browsing identity from the developer's identity, by running agents in a different OS user, a container, or a virtual machine. Bind the studio to loopback only and add a host firewall rule that blocks all non-loopback traffic to the default port 8081. Place it behind an authenticated reverse proxy that enforces auth on all paths, including any future WebSocket or `/api/*` routes. Run it under a low privilege account in a sandboxed user profile or container so any future agent driven RCE is contained to a dev profile, not a daily driver account.

The team also shared a set of Microsoft Defender advanced hunting queries that defenders can run against hosts running AutoGen Studio. The first looks for suspicious child processes spawned by an `autogenstudio` host process, including `cmd.exe`, `powershell.exe`, `pwsh.exe`, `bash.exe`, `wsl.exe`, `certutil.exe`, `mshta.exe`, `rundll32.exe`, `regsvr32.exe`, `curl.exe`, `wget.exe`, and `bitsadmin.exe`. The second looks for WebSocket reach outs to the AutoGen Studio MCP control plane carrying `server_params`. The third joins browser automation hosts navigating to non corporate domains during an AutoGen Studio session. If any of these queries surface activity during a period when the studio was running with a browsing or code execution agent, the guidance is to treat the host as a potential development environment compromise, review the host, rotate developer credentials and tokens accessible from it, and check whether anything was written to autostart locations.

At the model and agent layer, Azure AI Content Safety Prompt Shields detect user prompt injection and indirect prompt injection (cross prompt injection attack, or XPIA), which can catch an early stage of this chain when attacker controlled content steers an agent to navigate to a malicious page. Prompt Shields do not intercept the client side JavaScript execution that follows, but they provide an early interception point when initial navigation is triggered through indirect prompt injection. Microsoft Defender for Cloud Threat Protection for AI Services raises alerts on jailbreak, data leakage, and credential theft patterns observed against Azure hosted models, including models used by AutoGen agents when routed through Azure AI services. Microsoft Defender for Cloud AI Security Posture Management builds an AI bill of materials, scans infrastructure as code and container dependencies for vulnerable AI components, and runs attack path analysis. The Microsoft Foundry AI Red Teaming Agent and the open source PyRIT tool automate adversarial probing for indirect prompt injection, prohibited actions, and sensitive data leakage, and are worth running against your own prototypes before allowing them to browse the open web.

The shape of the broader agent security pattern

AutoJack is less interesting because of its individual bugs, each of which is a reasonable shortcut in a research grade prototype, and more interesting because of the chain's overall shape. Microsoft expects to see the same pattern across the ecosystem. A development tool exposes a powerful local control plane. That control plane is protected by an origin or localhost only assumption. The user routinely runs an agent on the same machine, and that agent is willing to render arbitrary web content. That triangle dissolves the localhost trust boundary.

The pattern is not hypothetical. Earlier research from teams including the same Microsoft Defender Security Research group has covered similar primitives in Semantic Kernel, and adjacent bug classes have surfaced in Langflow, which saw RCE under active attack months after a patch was shipped, and in a steady stream of vulnerabilities around agent tool use, MCP server implementations, and prompt injection surfaces. The McKinsey and Gartner projections about how many agents enterprises will deploy in 2026 and 2027 assume the surrounding toolchain will mature to handle this. It is not there yet, and the AutoJack chain is one of the cleaner demonstrations of what that gap looks up.

For organizations adopting AI agents, the practical takeaway is to retire the assumption that "local" means "safe." A developer laptop running an agent that browses the web is a small internet exposed endpoint with a confused deputy on the inside. Control plane authentication, command and executable allowlists, identity separation between the agent and the developer, and endpoint detection tuned for the specific child process patterns this chain produces are the four levers that move the needle. The AutoGen Studio team has shipped three of them as a default. The rest is on the rest of us.

For a deeper look at how to structure these controls across an enterprise program, the Enterprise AI Governance Checklist for 2026 walks through the same set of decisions for production deployments, and a recent piece on the MCP supply chain covers a related class of risk when an agent's tool list itself becomes the attack surface.