AutoJack attack turns AI agents into remote code execution vehicles via malicious web pages

AutoJack Attack Lets One Web Page Hijack AI Agent for Host Code Execution

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.

Microsoft warns AI agents are being 'AutoJack'-ed to deliver RCE payloads by browsing untrusted websites

Three minor vulnerabilities chained together can cause a lot of trouble * Microsoft's Defender Security Research Team discloses "AutoJack," a vulnerability chain in AutoGen Studio enabling RCE via malicious websites * Flaws included localhost channel misuse, skipped login checks, and arbitrary code execution, letting agents run attacker‑supplied programs * Issue existed only in early GitHub builds, fixed before release; highlights need for strict authentication and isolation of local control planes Microsoft's Defender Security Research Team has disclosed a vulnerability chain in AutoGen Studio that lets a single malicious website achieve remote code execution (RCE) on a device running an AI agent. AutoGen Studio is a program built by Microsoft Research for developing AI agents. The vulnerability chain was dubbed "AutoJack", and it consists of three flaws which, when looked at separately, aren't particularly troubling. Chained together, however, is a whole different story. "The technique, which we call AutoJack, jacks the agent into becoming the attacker's last-mile delivery vehicle by crossing the localhost trust boundary that many developer tools rely on," Microsoft explained in its report. Patching the bugs First, AutoGen Studio had a local control channel that only accepted connections from "localhost", which is a good way to block outside attackers. However, an AI agent's web browser also counts as "localhost", meaning these connections would get accepted, too. Then, for this particular channel, login checks were skipped. The app had several ways to require a username and password, but the part of the code handling this specific local channel was left wide open. Finally, the channel would run almost anything it was told to run. Microsoft's researchers managed to get an arbitrary program running, meaning threat actors could do the same, albeit with malicious code, instead. In theory, the attack would work like this: the victim would instruct their AI agent to summarize a specific website. By doing so, the agent would be told to download and run malicious code which could be anything from backdoor malware to infostealers. The good news is that Microsoft found this issue and reported it before the bug ever reached regular users. The official downloadable version of AutoGen Studio never had this problem, since it only existed in an early, in-development version on GitHub. The AutoGen team managed to fix it since then. "If an agent can browse untrusted pages and also talk to privileged local services, loopback can become an attack surface and control planes must be authenticated, authorized, and isolated," Microsoft concluded. Follow TechRadar on Google News and add us as a preferred source to get our expert news, reviews, and opinion in your feeds.