Hardening Against ClawJacked: Securing Local AI WebSockets
Everyone is buzzing about the "ClawJacked" flaw in OpenClaw today. For those who missed it, this is a critical issue (tracking as CVE-2026-1337) where a malicious website could initiate a WebSocket connection to a locally running OpenClaw agent and execute commands.
The scariest part is the quote from Oasis regarding the root cause:
"Our vulnerability lives in the core system itself – no plugins, no marketplace, no user-installed extensions – just the bare OpenClaw gateway, running exactly as documented."
If you are running local AI agents, you need to audit your configurations immediately. The vulnerability stems from insufficient Origin header validation on the WebSocket handshake. A simple proof-of-concept to verify if your version is still vulnerable looks like this:
import asyncio
import websockets
import
async def check_origin_target():
# Targeting the default OpenClaw gateway port
uri = "ws://localhost:8080/v1/agent"
# Simulating a request from a malicious origin
headers = {"Origin": "http://evil.com"}
try:
async with websockets.connect(uri, extra_headers=headers) as websocket:
print("[+] Connection accepted! System is vulnerable.")
await websocket.send(.dumps({"action": "status"}))
response = await websocket.recv()
print(f"Agent Response: {response}")
except Exception as e:
print(f"[-] Connection refused or error: {e}")
asyncio.run(check_origin_target())
If that script connects and returns data, your agent is exposed to any site you browse.
**Immediate Actions:**
- Update OpenClaw to the latest patched version immediately.
- Ensure the service is binding strictly to
127.0.0.1.
# Check if OpenClaw is listening on all interfaces (0.0.0.0) instead of localhost
ss -tulnp | grep openclaw
How are you all handling local AI isolation? Are you running these agents in distinct VMs/containers, or do you rely on network-level firewalls to block browser-initiated traffic?
We saw this in our dev environment last week. We actually moved all local AI gateways behind a local reverse proxy (Nginx) to handle the WebSocket upgrades and enforce strict Origin checks manually until the official patch was deployed. It adds a bit of latency, but it gives us centralized logging. Also, verify you aren't binding to 0.0.0.0 in your config files, that's the biggest risk factor for internal LAN pivoting.
This is essentially an evolution of DNS Rebinding but for WebSockets. Browser Same-Origin Policy (SOP) prevents the webpage from reading the response usually, but as Oasis noted, if the agent executes commands based only on the message payload received, the attacker gets one-way control. The Python snippet above is a great way to verify the fix works as expected. I'd also suggest checking your browser extensions—some of them modify Origin headers which could trigger weird behavior.
For detection in the SOC, we're looking for unexpected process spawns by the OpenClaw parent process. We've updated our Sigma rules to trigger on openclaw-agent (or similar binaries) spawning cmd.exe, powershell.exe, or /bin/sh. If the AI agent is just processing text or code completions, it should rarely, if ever, need to touch the system shell directly.
Verified Access Required
To maintain the integrity of our intelligence feeds, only verified partners and security professionals can post replies.
Request Access