Microsoft researchers have detailed an exploit chain, named
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 can reach a privileged local service on the same machine and spawn a process on the host.
No credentials, no sign-in screen, and no further user interaction once the agent loads the page. The attacker only has to get the agent to open it, and a planted link, a URL field, or a prompt injection will do.
The flaw sits in
AutoGen Studio, the open-source prototyping interface for Microsoft Research's AutoGen multi-agent framework. This is not a bug that hits everyone who installs the package, and the packaging detail is worth getting right.
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 (MCP) 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 does not install pre-releases 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 still no PyPI build carrying the main-branch hardening for them; the fixed code is in GitHub main at commit b047730.
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 on the assumption that 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, could run an attacker-chosen command under the account running AutoGen Studio.
Microsoft describes this as research, not an active campaign, and reported no exploitation in the wild. 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.
Microsoft reported the behavior to the Microsoft Security Response Center, and the maintainers hardened the main branch 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, and unknown IDs are refused. MCP routes now run through the normal authentication path. That hardening has not landed in a PyPI release yet.
What to do
A plain pip install autogenstudio gives you 0.4.2.2, which has no MCP route, so you are not affected.
If you installed a pre-release, you have the vulnerable handler and no patched PyPI build to move to. Pull from GitHub main at or after commit b047730. That is the real fix.
Until there is a release, separate the pieces the attack needs. Do not run AutoGen Studio on the same machine as a browsing or code-execution agent that touches untrusted content, because the chain only works when both share the same localhost. If they have to run together, isolate them in separate containers or VMs and run AutoGen Studio under a low-privilege account.
The AutoGen Studio bugs are patched in the 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 a similar localhost argument in its Semantic Kernel RCE research, tracked as CVE-2026-26030 and CVE-2026-25592.
Another localhost check is not enough. Authenticate the control plane, keep process execution behind an allowlist, and give the agent an identity that is not the developer's own session. Once an agent can browse the open web and reach privileged local services, localhost is no longer a trust boundary.
<small>Source: The Hacker News</small>
