Skip to content

AutoJack How a Single Page Can RCE the Host Running Your AI ... #2405

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
carlospolop wants to merge 1 commit into
base: master
Choose a base branch
from
+41 −0
Open

AutoJack How a Single Page Can RCE the Host Running Your AI ... #2405

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
41 changes: 41 additions & 0 deletions src/AI/AI-MCP-Servers.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -192,6 +192,46 @@ When testing MCP development environments, look for:
- OAuth / redirect flows that render attacker-controlled URLs inside the local UI.
- Proxy endpoints that accept arbitrary `command`, `args`, or server configuration JSON.

### Agent-Assisted Localhost MCP Hijacking (AutoJack pattern)

If an **AI browsing agent** runs on the same workstation as a privileged local MCP control plane, **localhost is not a trust boundary**. A malicious page rendered by the agent can reach `ws://127.0.0.1` / `ws://localhost`, abuse weak WebSocket trust assumptions, and turn the agent into a **confused deputy** that drives the local control plane.

This attack pattern needs three ingredients:

1. A **browser-capable or HTTP-capable agent** (Playwright/Chromium surfer, webpage fetcher, `requests`, `websockets`, etc.) that can load attacker-controlled content.
2. A **powerful localhost service** (MCP bridge, inspector, agent studio, debug API) that assumes loopback access or a localhost `Origin` is trustworthy.
3. A **dangerous parameter** reachable from the request that ends in process execution, file write, tool invocation, or other high-impact side effects.

In Microsoft's **AutoJack** research against a development build of **AutoGen Studio**, attacker-controlled web content opened a local MCP WebSocket and supplied a base64-encoded `server_params` object that was deserialized into `StdioServerParams`. The `command` and `args` fields were then passed to the stdio launcher, so the WebSocket request itself became a local process-spawn primitive.

Typical audit checks for this pattern:

- **Origin-only WebSocket protection** (`Origin: http://localhost` / `http://127.0.0.1`) with no real client authentication. A local agent can satisfy that assumption because it runs on the same host.
- **Middleware auth exclusions** for `/api/ws`, `/api/mcp`, or similar upgrade paths, assuming the WebSocket handler will authenticate later. Verify the handler really does so at handshake/accept time.
- **Client-controlled server launch parameters** such as `command`, `args`, env vars, plugin paths, or serialized `StdioServerParams` blobs.
- **Agent/browser coexistence** on the same machine as the developer control plane. Prompt injection or attacker-controlled URLs/comments can become the delivery vector.

Minimal hostile payload shape:

```json
{
"type": "StdioServerParams",
"command": "calc.exe",
"args": [],
"env": {"pwned": "true"}
}
```

If the service accepts a query-string or message-field version of that object, test Unix/Windows variants such as `bash -c 'id'` or `powershell.exe -enc ...` as well.

#### Durable fixes

- Do **not** trust loopback or `Origin` alone for MCP/admin/debug control planes.
- Enforce **authentication and authorization on every WebSocket route**, not only on REST endpoints.
- Bind dangerous launch parameters **server-side** (store them by session ID or server policy) instead of accepting them from the WebSocket URL/body.
- **Allowlist** which binaries or MCP servers may be spawned; never forward arbitrary `command` / `args` from the client.
- Isolate browsing agents from developer services using a **different OS user, VM, container, or sandbox**.

### Persistent Code Execution via MCP Trust Bypass (Cursor IDE – "MCPoison")

Starting in early 2025 Check Point Research disclosed that the AI-centric **Cursor IDE** bound user trust to the *name* of an MCP entry but never re-validated its underlying `command` or `args`.
Expand Down Expand Up @@ -319,6 +359,7 @@ The **MCP Attack Surface Detector (MCP-ASD)** Burp extension turns exposed MCP s
This workflow makes MCP endpoints fuzzable with standard Burp tooling despite their streaming protocol.

## References
- [AutoJack: How a single page can RCE the host running your AI agent](https://www.microsoft.com/en-us/security/blog/2026/06/18/autojack-single-page-rce-host-running-ai-agent/)
- [CVE-2025-54136 – MCPoison Cursor IDE persistent RCE](https://research.checkpoint.com/2025/cursor-vulnerability-mcpoison/)
- [Metasploit Wrap-Up 11/28/2025 – new Flowise custom MCP & JS injection exploits](https://www.rapid7.com/blog/post/pt-metasploit-wrap-up-11-28-2025)
- [GHSA-3gcm-f6qx-ff7p / CVE-2025-59528 – Flowise CustomMCP JavaScript code injection](https://github.com/advisories/GHSA-3gcm-f6qx-ff7p)
Expand Down