TL;DR

• what: AutoJack chains three weaknesses in AutoGen Studio's MCP WebSocket so an attacker web page, loaded by a local AI browsing agent, runs arbitrary commands on the host.
• impact: Any page the agent opens can spawn a process under the account running AutoGen Studio with no credentials and no further user interaction.
• fix: The real fix is GitHub main at commit b047730 (PR #7362); no patched PyPI release exists yet, so stay on stable 0.4.2.2 or pull from source.
• who: Anyone who ran AutoGen Studio pre-releases 0.4.3.dev1 or 0.4.3.dev2 alongside a browsing or untrusted-content agent on the same machine.

Microsoft researchers detailed an exploit chain called AutoJack that turns an AI browsing agent into a delivery vehicle for remote code execution. Steer the agent to load an attacker's web page, and that page's JavaScript reaches a privileged local service on the same machine and spawns a process on the host. No credentials, no sign-in, no further interaction once the page loads. A planted link, a URL field, or a prompt injection is enough to get the agent to open it.

The flaw sits in AutoGen Studio, the open-source prototyping interface for Microsoft Research's AutoGen multi-agent framework. The proof of concept used a "Web Content Summarizer" agent that, when fed an attacker URL, pops calc.exe on the developer's desktop, launched by the AutoGen Studio process itself. Microsoft calls this research, not an active campaign, and reports no exploitation in the wild.

The packaging detail that decides whether you are exposed

This is not a bug that hits everyone who installs the package, and the packaging story matters. A plain pip install autogenstudio pulls the current stable release, 0.4.2.2, the build Microsoft inspected, and it has no Model Context Protocol route at all. That is the basis for Microsoft's statement that the vulnerable MCP WebSocket surface "was never included in a PyPI release." It holds for the stable build.

But the vulnerable handler did ship to PyPI, in two pre-release builds: 0.4.3.dev1 and 0.4.3.dev2. The Hacker News downloaded and inspected both. The MCP WebSocket route is present, the handler takes the command to run straight from the request, and it does not authenticate the caller. Neither build has been yanked. pip will not install a pre-release unless you pass --pre or pin the version, so a plain install was never exposed. Anyone who installed one of those pre-releases was.

⚠️ There is no patched PyPI build to move to — The hardening lives only in GitHub main at commit b047730. No PyPI release carries it yet. If you installed a pre-release, upgrading through PyPI does not help. Pull from source at or after b047730, or stay on stable 0.4.2.2.

How the chain works

AutoJack chains three weaknesses in the MCP WebSocket. First, the socket trusted localhost, a check meant to block a normal browser pointed at a malicious site. But a browsing agent running on the same box is localhost, so anything it loads inherits that localhost identity and passes the check. Second, the authentication middleware skipped MCP paths, assuming the handler would verify tokens itself. It never did, so the socket accepted unauthenticated connections regardless of the configured auth mode. Third, the endpoint took a command straight from a request parameter and ran it, with no allowlist on which executable could launch.

Put together, a page on the open internet, rendered by a local agent, runs an attacker-chosen command under the account running AutoGen Studio. Microsoft reported the behavior to MSRC, and the maintainers hardened main in commit b047730 (PR #7362). The fixed handler no longer reads the command from the URL; parameters are stored server-side behind a one-time session ID, unknown IDs are refused, and MCP routes now run through the normal authentication path.

What to do now

• A plain pip install autogenstudio gives you 0.4.2.2, which has no MCP route, so you are not affected.
• If you installed 0.4.3.dev1 or 0.4.3.dev2, you have the vulnerable handler. Pull from GitHub main at or after commit b047730. That is the real fix.
• Until there is a release, do not run AutoGen Studio on the same machine as a browsing or code-execution agent that touches untrusted content. The chain only works when both share the same localhost.
• If they must run together, isolate them in separate containers or VMs and run AutoGen Studio under a low-privilege account.

The pattern outlives the patch

The AutoGen Studio bugs are patched in source. The pattern is not. Microsoft expects the same shape in other agent frameworks: a local service with too much power, a localhost check treated as security, and an agent that opens untrusted pages. THN saw it last month in ChatGPhish, where ChatGPT's page summaries became a phishing vector. Microsoft made the same localhost argument in its Semantic Kernel RCE research, tracked as CVE-2026-26030 and CVE-2026-25592.

Localhost is not a trust boundary — Once an agent can browse the open web and reach privileged local services, anything it loads speaks as localhost. Authenticate the control plane, keep process execution behind an allowlist, and give the agent an identity that is not the developer's own session. Another localhost check is not enough.

For security teams, the practical takeaway is to inventory where AI agents and local agent-tooling services run on the same host, especially on developer workstations where pre-release packages get installed casually. Treat any local MCP or agent control plane as an attacker-reachable surface the moment the agent can render untrusted content, and apply the same authentication, allowlisting, and least-privilege rules you would to any internet-facing service.

Originally published on RedEye Threat Intelligence.