Paper Published: Apr 18, 2026

OpenClaw 'ClawJacked': Website-to-Local Agent Takeover via Loopback Trust and WebSocket Abuse

Oasis Security showed that any website could open a WebSocket to OpenClaw's localhost gateway, skip origin checks by claiming a CLI client, then brute-force password auth because loopback attempts were exempt from rate limits. The fix is already out; the lesson is to stop treating localhost as identity and to scope every agent session and RPC method as privileged.

Agentic AIWebSocket SecurityLocalhost TrustIdentity & Access
7 applicable AIDEFEND defenses
Source: Technical Analysis of Cross-Origin WebSocket Exploitation in OpenClaw 
By Elad Luz · Original article: Feb 26, 2026

Threat Analysis

  • Three trust failures chained together. Origin validation applied only to certain client IDs, localhost pairings were auto-approved, and loopback password guesses skipped throttling and logging.
  • The browser was the real remote party. In Chrome, Edge, and most Firefox setups, a public HTTPS page could open ws://127.0.0.1:18789/ws; trusting loopback over origin collapsed the boundary.
  • Authenticated impact was full control-plane access. The whitepaper shows reachable methods for chat hijack, config changes, node command dispatch, agent file writes, scheduled jobs, and log access.
  • Passwords were not meaningful protection. Oasis measured 300+ guesses per second from browser JavaScript, so a human-chosen gateway password was effectively bypassable.
  • Local agent gateways are admin APIs. Pairing, session creation, and high-impact RPC methods need the same hardening you would apply to any internet-facing control plane.

Applicable AIDEFEND Defenses (7)

AID-M-009.003
Agent Identity, Delegation Lineage & Runtime Authorization
Very High
Bind gateway sessions to a verified client identity and short-lived session credential, not to a claimed client ID plus loopback source address. A browser-opened WebSocket should never inherit CLI- or node-grade authority just because it originates from 127.0.0.1.
AID-H-019.004
Intent-Based Dynamic Capability Scoping
Very High
A fresh session should receive only the minimal RPC set it needs. Methods such as config.patch, node.invoke, skills.install, agents.files.set, and cron.add should stay outside the default envelope unless a separately trusted workflow grants them.
AID-I-008.002
Cross-Origin Read/Write Segmentation with Step-Up Confirmation
Very High
Treat browser-to-localhost and public-origin-to-loopback transitions as sensitive write boundaries. A page from the public web should not be able to open an administrative WebSocket, pair a device, or trigger state changes on a local agent gateway without explicit step-up approval.
AID-M-009.002
Authority Envelope & Action Risk Classification
High
Treat device pairing, configuration mutation, node command execution, persistent job creation, and cross-device data access as high-risk control-plane actions that always need stronger authorization than ordinary chat or read-only status calls.
AID-D-005.002
Security Monitoring & Alerting for AI
Medium
Alert on rapid loopback auth failures, new device pairings, client-ID/origin mismatches, and first-time use of node.invoke, config.patch, or cron.add. The whitepaper shows localhost guesses were not even counted; defenders need that telemetry.
AID-D-015.002
High-Risk Action Confirmation Telemetry & Bypass Detection
Medium
Pairing a device, opening administrative WebSockets, and invoking methods such as node.invoke should leave confirmation evidence. Correlating pairing prompts, approval records, session identity, and execution events helps detect silent pairings or RPC calls that happened without the expected user step-up.
AID-I-004.006
Agent Identity & Persistent State File Write Protection
Medium
Post-auth compromise should not automatically become persistent compromise. Protect agent identity files, memory/state files, and scheduled-task definitions from silent modification so an attacker cannot turn agents.files.* or automation endpoints into a durable backdoor.

What Defenders Should Do Now

  • Inventory OpenClaw or similar local agent gateways across endpoints, especially anything listening on port 18789, and upgrade all instances to version 2026.2.25 or later.
  • If password authentication is still enabled, prefer high-entropy tokens, remove stale paired devices, and rotate device tokens after any suspected exposure.
  • Put browser-originated management actions behind explicit approval or an outright deny path: new pairings, node.invoke, config writes, agent file writes, skill installs, and scheduled jobs.
  • Log and alert on loopback auth bursts, client-ID/origin mismatches, first-time pairings, and unexpected administrative RPC usage.
  • Audit what each OpenClaw instance can actually reach - AI provider keys, messaging channels, shell execution, workspace files, and logs - then cut standing access to the minimum necessary.

1 additional consideration

Browser-to-localhost exposure regression testing

Beyond the techniques mapped above, teams shipping local AI assistants should also add release-time regression testing that treats arbitrary websites as the attacker and probes localhost HTTP and WebSocket surfaces for origin confusion, silent pairing, and loopback trust assumptions.
Recommendation: Maintain a harness that opens the local service from a public HTTPS page in Chrome, Edge, Firefox, and Safari, then verifies origin checks, pairing prompts, auth throttling, and administrative method exposure before each release.

Conclusion

OpenClaw is a strong reminder that localhost is not a security boundary when the browser can still speak WebSocket to it. The defensive floor is to bind agent authority to verified runtime identity, narrow every session and RPC method to the smallest usable scope, and test local agent gateways the way you would test any privileged control-plane API.