AutoJack: A Drive-By to RCE Hiding in AutoGen Studio's Dev UI
A prototyping tool nobody treated as production becomes a one-click code execution chain. The fix is out. The pattern is not.
Microsoft has patched a vulnerability chain in AutoGen Studio, the GUI front-end for its AutoGen agent framework, that turned a casual visit to a malicious webpage into arbitrary command execution on the developer's host.
The researchers calling it AutoJack chained three things: a permissive CORS policy on the local AutoGen Studio web server, a server-side request forgery primitive, and an agent tool-use path that happily executed Python passed in as part of a task. Visit the wrong site while your dev server was running, and a remote origin could pivot through the API, instruct an agent to run code, and land shell on your laptop.
The failure mode here is depressingly familiar.
AutoGen Studio is pitched as a prototyping interface — something you spin up locally, click around, build a multi-agent workflow, then hand off to engineering. In practice, "local dev tool" became "local dev tool with a Python interpreter on the other end of an HTTP endpoint that trusts any origin." That is not a prototyping risk profile. That is an RCE surface.
Microsoft tracked the issue and shipped fixes in AutoGen Studio releases that tighten CORS handling and constrain how user-supplied content reaches the agent's code execution tools. If you're running anything older than the patched build, update before you next open a browser tab.
A few things worth flagging for anyone running agent frameworks in dev or staging:
- Local-only bind addresses are not a security control if the browser can reach them.
localhostis a reachable origin from every tab you open. - Any agent that has
PythonCodeExecutionTool,ShellTool, or a homegrown equivalent wired in should be treated as a remote shell, full stop. The threat model is not "what does the LLM decide to do." It is "what does any input that reaches the prompt decide to do." - CORS misconfigurations on developer tooling are showing up in advisory after advisory. Jupyter, Ollama front-ends, now this. The pattern is consistent: ship fast for DX, lock down later, get bitten in between.
One thing the post-mortem will say, eventually, is that the security boundary for agent tools needs to live below the HTTP layer — sandboxing the executor, not trusting the caller. Microsoft's patch addresses the immediate chain. It does not change the underlying architecture, where an agent with code-execution tools is one input-validation slip away from being a backdoor.
Operational takeaway: audit every agent dev environment on your network for tools that shell out, and assume the web UI in front of it is internet-reachable until proven otherwise.
