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.
Key points
- Microsoft patched a vulnerability chain in AutoGen Studio that allowed arbitrary code execution via a malicious webpage visit.
- The chain combined a permissive CORS policy, a server-side request forgery primitive, and an agent code-execution path.
- Local dev tools that bind to localhost are reachable from any browser tab, a threat model most teams skip.
- Any agent wired to a code-execution tool should be treated as a remote shell regardless of where it runs.
- Microsoft's patch tightens the immediate chain but does not restructure the underlying executor architecture.
What did AutoJack actually do?
The researchers who named it AutoJack chained three things: a permissive CORS policy on AutoGen Studio's local web server, a server-side request forgery primitive, and an agent tool-use path that executed Python passed in as task content. 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. One tab. One click.
We first covered the AutoJack research on 19 June 2026, when Microsoft uncovered the localhost exposure before a patch was ready.
Should you worry if you've already updated?
The patched releases tighten CORS handling and constrain how user-supplied content reaches the agent's code execution tools. If you're on anything older, update before you open another browser tab. That's the short answer.
The longer answer is that this fix closes a specific chain. It doesn't change the architecture underneath: an agent with code-execution tools wired in is one input-validation slip away from being a backdoor. Microsoft's patch is correct and necessary. It is not a redesign.
Why do dev tools keep landing in advisories?
AutoGen Studio is pitched as a prototyping interface. Spin it up locally, build a multi-agent workflow, hand off to engineering. What it actually was: a Python interpreter on the far end of an HTTP endpoint that trusted any origin. That's not a dev-tool risk profile. That's an RCE surface dressed as a sandbox.
The same pattern appeared in the LangGraph SQLi-to-RCE chain we reported on 12 June 2026. Ship fast for developer experience, lock down later, get caught in between. Jupyter had it. Ollama front-ends had it. AutoGen Studio had it. The through-line is consistent: prototyping UIs inherit the security assumptions of a throwaway environment and then outlive them.
CORS misconfigurations on developer tooling are not new, but they're landing harder now because the thing on the other end of the misconfigured endpoint is no longer a JSON blob. It's an agent with shell access.
What should you actually do?
localhost is reachable from every tab you open. Binding to a loopback address is not a security control when the browser is already past it. Any agent that has a Python executor, a shell tool, or a homegrown equivalent wired in should be in your threat model as a remote shell, full stop. The question isn't what the LLM decides to run. The question is what any input that reaches the prompt decides to run.
Audit every agent dev environment on your network for tools that shell out. Assume the web UI in front of it is internet-reachable until you have evidence otherwise. The security boundary for agent tools needs to sit below the HTTP layer, in the executor sandbox, not in caller trust.
The post-mortem template for this class of bug is already written. It'll say the team knew the tool had code execution, assumed the local bind was protection enough, and found out it wasn't. We've read that document before.
