Localhost Is Not a Trust Boundary: What ClawJacked Proves About Agent Gateways
Written by the Rafter Team
In February 2026, we published a security audit of Open Claw — a multi-platform AI agent controlling WhatsApp, Slack, Telegram, Discord, and eight other messaging services from a single LLM brain. We identified tool misuse, credential exposure, and prompt injection as the top risks. Our assessment: the attack surface was enormous, and each platform integration multiplied every vulnerability class by twelve.
Two weeks later, Oasis Security proved us right.
Their ClawJacked research (CVE-2026-25253) demonstrated that any malicious website could connect to a developer's local OpenClaw gateway and take full control of the agent. Not through a sophisticated exploit chain. Through a WebSocket connection to localhost that the gateway assumed was trusted.
The vulnerability was patched in under 24 hours. But ClawJacked isn't interesting because of the specific bug. It's interesting because it validated a systemic problem: every agent gateway, MCP server, and local AI service that trusts localhost is making the same mistake.
What ClawJacked Actually Did
OpenClaw's gateway binds to localhost and exposes a WebSocket interface. The threat model: only local processes can connect, so any connection is trusted. The reality: browsers permit cross-origin WebSocket connections to localhost, bypassing the CORS protections that would block a standard HTTP request.
The attack chain:
- Developer visits a malicious website (or any site with injected JavaScript)
- JavaScript opens a WebSocket to
ws://localhost:<gateway-port> - The script brute-forces the gateway password — there was no rate limiting for localhost connections
- Once authenticated, the attacker registers as a trusted device with automatic approval
- Full control: interact with the AI agent, dump configuration, enumerate connected devices, read conversation logs
At time of disclosure, 42,665 OpenClaw instances were directly exposed to the internet. But even the ones behind NAT — the "safe" developer laptop setups — were vulnerable through the browser.
No malware download. No phishing for credentials. Just a web page with some JavaScript.
The CVE Cluster That Followed
ClawJacked wasn't an isolated finding. It was the first of eight critical CVEs in OpenClaw disclosed over a six-week period:
| CVE | Severity | Type |
|---|---|---|
| CVE-2026-25253 | High | ClawJacked — WebSocket gateway takeover |
| CVE-2026-25593 | Critical | Remote code execution |
| CVE-2026-24763 | Critical | Command injection |
| CVE-2026-25157 | High | Server-side request forgery |
| CVE-2026-25475 | High | Authentication bypass |
| CVE-2026-26319 | Critical | Path traversal + RCE |
| CVE-2026-26322 | Critical | Path traversal + RCE |
| CVE-2026-26329 | Critical | Path traversal + RCE |
This pattern matters. When you find one localhost trust assumption, you usually find more. The first CVE isn't the vulnerability — it's a signal of systemic architectural debt. OpenClaw's gateway was built on the premise that local access equals trusted access. Once that premise was challenged, the entire security model unraveled.
The Localhost Trust Assumption Is Everywhere
ClawJacked exploits the same trust model failure we documented in December 2025 with CVE-2025-66414 — DNS rebinding against MCP servers on localhost. Different tools, different exploit techniques, same underlying assumption:
| CVE-2025-66414 (MCP DNS Rebinding) | CVE-2026-25253 (ClawJacked) | |
|---|---|---|
| Target | MCP servers on localhost | OpenClaw gateway on localhost |
| Entry vector | Malicious website | Malicious website |
| Technique | DNS rebinding (re-resolve domain to 127.0.0.1) | Cross-origin WebSocket (direct connection to localhost) |
| Why it works | MCP server accepts any Host header | Gateway assumes localhost connections are trusted |
| Impact | File exfiltration, code modification | Full agent control, credential theft |
| Fix | Host header validation | Rate limiting, auth hardening |
Two different exploit techniques. Same threat model gap. If your local service trusts connections because they come from 127.0.0.1, you're vulnerable to both.
The list of local services making this assumption is long:
- MCP servers (filesystem, Git, database tools)
- AI agent gateways (OpenClaw, and likely others)
- Development servers (Vite, Next.js dev, webpack-dev-server)
- Local APIs (Docker, Kubernetes, database admin panels)
- IDE backends (language servers, debuggers)
Every one of these trusts localhost. Every one of them is reachable from the browser.
Why "Just Add Auth" Isn't Enough
The obvious fix is authentication. OpenClaw had a password — the problem was that it could be brute-forced without rate limiting. The MCP SDK added Host header validation. Both are necessary patches.
But authentication on localhost creates a UX problem that developers routinely solve by disabling it. The entire value proposition of local dev tools is frictionless access. If your MCP server requires an API key, you need to store that key somewhere. If it requires mTLS, you need certificates. Developers will choose --no-auth every time, because the threat model ("I'm on my own machine") feels safe.
The real fix requires changing the threat model, not just adding a password:
1. Stop Binding to TCP
If your local service doesn't need to be reachable from the browser, don't use TCP. Unix domain sockets, stdio pipes, and named pipes are all immune to browser-based attacks because browsers can only initiate TCP connections.
The MCP specification supports stdio transport. Use it. OpenClaw should consider a local socket interface for developer workstations.
2. Assume the Browser Is Hostile
If your service must use TCP (because it serves a web UI, for example), design as if every request might come from a malicious website:
- Validate Origin headers on WebSocket upgrades
- Validate Host headers on HTTP requests
- Rate-limit authentication even on localhost
- Require CSRF tokens for state-changing operations
- Never auto-approve device registration or trust establishment
3. Separate Control Plane From Data Plane
OpenClaw's mistake was exposing device registration, agent control, and configuration read on the same interface. Even if the data plane must be accessible locally, the control plane (trust decisions, device approval, configuration changes) should require elevated authentication — a second factor, a separate port with stricter controls, or an out-of-band approval mechanism.
What Our Audit Got Right (and What We Missed)
In our Open Claw security audit, we focused on the application-layer attack surface: prompt injection across twelve platforms, tool misuse with multi-platform credentials, data leakage through the LLM context. These are real risks, and they remain unaddressed.
What we didn't predict was that the gateway itself would be the entry point. We assessed the architecture assuming the attacker had to reach the agent through one of the messaging platforms. ClawJacked showed that the attacker could skip all of that and go straight to the control interface through the browser.
The lesson: when auditing AI agent systems, don't just analyze what the agent can do. Analyze how the agent's infrastructure is exposed. The gateway, the MCP servers, the local configuration endpoints — these are the new perimeter, and they're often less hardened than the agent itself.
What to Check Right Now
If you run any AI agent or MCP infrastructure on localhost:
- Audit your listening ports. Run
lsof -i -P | grep LISTENand identify every service bound to localhost. For each one, ask: what happens if a malicious website connects to this? - Check for WebSocket endpoints. WebSocket connections bypass CORS. If your local service exposes a WebSocket, it's reachable from any website.
- Test rate limiting. Try brute-forcing your own local service from a script. If there's no lockout after 100 failed attempts, an attacker can do the same from JavaScript.
- Review auto-trust mechanisms. Does your tool auto-approve new connections, devices, or clients? If so, an attacker who connects once is trusted forever.
- Switch to non-TCP transports. If your MCP server supports stdio, use stdio. If your agent gateway can use Unix sockets, use Unix sockets.
ClawJacked was patched in 24 hours. The assumption it exploited has been baked into developer tooling for decades.
Related reading:
- Open Claw Security Audit: What We Found Attacking a Multi-Platform AI Agent — our architectural analysis that predicted these risk categories
- DNS Rebinding and Localhost MCP: Your Dev Server Is a Production Attack Vector — the parallel localhost trust failure in MCP servers
- The AI Agent Attack Surface Is Real — pattern analysis across five real incidents
References: