On June 18, 2026, Microsoft's security researchers disclosed AutoJack, an exploit chain targeting AutoGen Studio, Microsoft Research's open-source interface for prototyping multi-agent AI workflows. In the reported attack, an AI browsing agent visiting a malicious webpage could cause Studio to execute commands under the developer's local account.

The chain combined three weaknesses: a localhost origin check that the attack could pass, missing authentication on MCP routes, and an endpoint that accepted arbitrary subprocess commands. Remote code execution, or RCE, followed from connecting those weaknesses together.

The affected versions were limited to two development builds. The stable package did not contain the vulnerable route. That narrow scope matters, even though the combination of untrusted web content and privileged local services deserves attention beyond this particular tool.

How the exploit chain worked

AutoGen Studio provides a local web interface for designing and testing workflows built on Microsoft's AutoGen multi-agent framework. Its pre-release builds 0.4.3.dev1 and 0.4.3.dev2 added support for Model Context Protocol, or MCP, a standardized interface for connecting agents to external tools. Studio exposed that support through a WebSocket endpoint at ws://localhost:8081/api/mcp/ws/.

A WebSocket keeps a connection open so a client and server can exchange messages. In this case, the endpoint also provided a route to launching a local process.

The localhost origin check

The MCP WebSocket checked the Origin header against an allowlist containing http://127.0.0.1 and http://localhost. The intended restriction was to accept connections from trusted local content.

The reported attack used a browsing agent running on the same machine. The agent rendered an attacker-controlled webpage, whose JavaScript opened a connection to the local WebSocket endpoint. Microsoft's account describes that connection as passing the localhost origin check. The attack therefore reached an endpoint intended for Studio's local front end.

Authentication skipped the MCP routes

Studio supported authentication through GitHub OAuth, Microsoft's MSAL, and Firebase. Its authentication middleware explicitly skipped /api/mcp/* paths, however, on the assumption that the MCP handler would verify tokens itself.

The handler did not perform that verification. MCP WebSocket connections were accepted without authentication, regardless of the authentication mode configured elsewhere in Studio. Enabling sign-in for the application therefore did not protect this route.

Connection parameters became executable commands

The WebSocket endpoint accepted a server_params URL query parameter. It contained base64-encoded JSON with command and args fields, which were passed directly to stdio_client(), a function that spawns a subprocess.

There was no command allowlist or sanitization. A payload such as {"command": "powershell.exe", "args": ["-Command", "..."]} could instruct Studio to launch PowerShell under the developer's account. The permissions of that account determined what the resulting process could access.

The reported attack followed four steps:

  1. An attacker hosted a webpage containing a WebSocket call to ws://localhost:8081/api/mcp/ws/?server_params=<base64_payload>.
  2. A developer's browsing agent visited the page, perhaps through a planted link, a document it was asked to summarize, or prompt injection.
  3. The page's JavaScript opened the WebSocket connection and passed the origin check.
  4. Studio launched the binary specified in the payload under the developer's account.

Once the agent visited the page, the reported chain required no further user clicks or approval. The researchers described the combination of an internet-hosted webpage and a locally running AutoGen agent as a remote code execution primitive.

Affected builds and the fix

As of the June 18 disclosure, the vulnerable code had never shipped in a stable PyPI release. The current production package, autogenstudio 0.4.2.2, did not contain the MCP WebSocket route. Only 0.4.3.dev1 and 0.4.3.dev2 carried the vulnerable handler.

Both development builds remained available on PyPI without being yanked at disclosure. Developers who installed a development or pre-release package therefore needed to check the installed version rather than assume that package availability meant it was unaffected.

Microsoft's fix landed in commit b047730 in the upstream repository. It made two structural changes. Command parameters were no longer accepted through URL query strings; they were stored server-side behind one-time session tokens. The MCP paths were also removed from the authentication middleware's skip-list.

For installations tracking the pre-release code, the stated remediation was to pull from the main branch at or after that commit. The stable 0.4.2.2 package was outside the affected scope.

A local endpoint still needs protection

The broader concern is the assumption that a service listening on localhost can trust anything able to reach it. Developer tools often expose powerful local operations because they are meant to be used by an editor, a front end, or another trusted process. A browsing agent introduces untrusted webpages into the same working environment.

That creates a boundary worth examining: can content rendered by the agent reach a service that can execute commands or access sensitive files? In AutoJack, the reported chain crossed that boundary through a WebSocket endpoint whose authentication and command controls were missing.

MCP makes this relevant to more than one application because it gives agents a common way to use external tools. Local MCP processes are part of setups involving Claude Desktop integrations, Cursor's MCP tooling, and custom agent frameworks. Their presence alone does not establish that they expose an unauthenticated WebSocket or share AutoJack's weaknesses. Their transport, authentication, and execution permissions need to be checked.

Microsoft's researchers warned that the vulnerability pattern likely exists in other agent frameworks. They identified the combination of excessive privileges in local services, localhost treated as a security boundary, and agents accessing untrusted web content.

That is a reason to audit similar designs, not evidence that every framework is vulnerable. AutoJack demonstrates a specific instance of a broader vulnerability class: untrusted content reaching a privileged service through inadequate access controls.

Practical checks for local agent environments

The immediate priority is identifying affected Studio installations. Beyond that, the useful work is checking what browsing agents can reach and what those services can do.

  • Separate browsing workloads from privileged local services. Agents that render external URLs and execute JavaScript should be isolated from services with broad execution rights. Separate containers or virtual machines can provide that separation when their networking and access permissions enforce it. This adds setup and maintenance work, but limits the services and files exposed to a compromised browsing environment.
  • Inspect local listeners. On macOS or Linux, use lsof -i -P -n | grep LISTEN. On Windows, use netstat -ano | findstr LISTEN. For recognized MCP services, check whether authentication is required, whether executable commands are allowlisted, and how origins are validated. A localhost address alone is not an access-control policy.
  • Require authentication on exposed MCP endpoints from the first version. Check the route itself, not just the application's sign-in screen. AutoJack's authentication gap existed because the middleware and handler each left enforcement to the other.
  • Avoid development builds for production-adjacent work. Stable 0.4.2.2 was unaffected, while the two affected packages were explicitly marked as development versions. New integrations can introduce endpoints and execution paths that are absent from stable releases. Access to those features comes with additional review work.

Related risks need separate controls

AutoJack follows a broader survey of RCE vulnerabilities in AI agent frameworks that Microsoft's researchers published earlier in 2026. It adds a concrete example of how an agent's browsing capability can expose a local execution service.

Prompt injection and MCP supply chain attacks are related concerns, but they work differently. Prompt injection places malicious instructions in content an agent processes. A supply chain attack compromises a tool or dependency the agent uses. AutoJack's reported execution path relied on webpage JavaScript reaching a vulnerable local endpoint; prompt injection was one possible way to steer the agent to that page.

Those distinctions affect the defenses. Better handling of untrusted instructions does not replace authentication on local services. Authentication does not replace limits on executable commands or process permissions. A local agent environment needs controls at the points where web content, tool access, and operating-system privileges meet.