ClawJacked: Abusing OpenClaw's Local WebSocket for AI Agent Hijacking
Just saw the report on Hacker News regarding the ClawJacked flaw in OpenClaw. This is a textbook case of why we need to treat local AI agents with the same suspicion as remote services.
The vulnerability allows a malicious website to interact with a locally running OpenClaw agent via a WebSocket connection. Since it's in the core gateway, even 'clean' installs are vulnerable. The core issue is likely a lack of proper Origin validation on the WebSocket handshake, effectively turning a local tool into a remote proxy for attackers.
Detection & Mitigation
If you are running OpenClaw, you need to verify that the gateway isn't listening on 0.0.0.0. It should be restricted to 127.0.0.1 to prevent external sites from hitting it.
Here's a quick Python snippet to audit your listening ports for the default OpenClaw gateway (assuming port 8080):
import psutil
import socket
def audit_openclaw():
print("Scanning for OpenClaw Gateway...")
for conn in psutil.net_connections(kind='inet'):
if conn.status == 'LISTEN' and conn.laddr.port == 8080:
if conn.laddr.ip == '0.0.0.0' or conn.laddr.ip == '::':
print(f"[ALERT] Gateway listening on {conn.laddr.ip} - Vulnerable to ClawJacked!")
else:
print(f"[SAFE] Gateway listening on loopback: {conn.laddr.ip}")
if __name__ == "__main__":
audit_openclaw()
Are we seeing more of these 'local agent' vulnerabilities popping up as AI adoption grows? How are you guys segregating these tools from your browsing environments?
This is essentially Cross-Site WebSocket Hijacking (CSWSH). If the OpenClaw gateway doesn't validate the Origin header during the handshake, the browser will happily send the local connection cookies along with the request from a malicious site.
I'd recommend setting up a local firewall rule (using iptables or Windows Firewall) to block non-local loopback traffic to the agent's port entirely. That way, even if the app logic is flawed, the network layer stops the exfiltration.
We are hunting for this right now in our SOC. We've updated our Sigma rules to look for browser processes (chrome.exe, msedge.exe) initiating outbound WebSocket connections to non-standard ports on localhost.
It's a bit noisy with devs testing local apps, but given the impact of an AI agent hijack, we'd rather tune out the false positives than miss a compromise. Has anyone confirmed if the patch fixes the Origin validation or just changes the default binding?
Just pushed the update via SCCM, but this highlights a bigger architectural issue. Developers keep assuming that because a service listens on 'localhost', it's safe.
With the complexity of modern browsers and extensions, 'localhost' is just another untrusted network zone in my book. We need to start treating local AI services like API endpoints—require authentication tokens, enforce CORS, and stop trusting implicit trust boundaries.
Solid analysis. From an endpoint detection standpoint, we should also monitor for process lineage anomalies. If OpenClaw's agent is usually a standalone service, a browser process spawning it is a massive red flag. We're currently rolling out a custom detection rule to flag this specific parent-child relationship.
Here’s a basic query to start hunting in your logs:
DeviceProcessEvents
| where InitiatingProcessFileName in~ ("chrome.exe", "msedge.exe", "firefox.exe")
| where FileName in~ ("openclaw-agent.exe", "python.exe")
| where ProcessCommandLine contains "websocket"
Has anyone confirmed if the agent validates the handshake after the connection is established, or is it purely the missing Origin header?
Spot on regarding the localhost assumption. For those verifying impact, a quick check with curl against the WebSocket endpoint confirms if the Origin check is missing. If the handshake returns 101 Switching Protocols with a spoofed Origin, you're wide open.
curl -i -N \
-H "Connection: Upgrade" \
-H "Upgrade: websocket" \
-H "Origin: http://evil.com" \
http://localhost:8080/agent
Verified Access Required
To maintain the integrity of our intelligence feeds, only verified partners and security professionals can post replies.
Request Access