Security researchers discover ClawJacked, a critical vulnerability allowing malicious websites to hijack locally hosted AI agents through WebSocket-based SSRF.
What ClawJacked Exploits
ClawJacked is a critical vulnerability class targeting AI agents that run on a developer’s own machine. Many local agents expose a control surface over the network so a browser, IDE plugin, or dashboard can talk to them. That surface is often a WebSocket endpoint bound to localhost. The design assumption is simple: if it only listens on the loopback interface, only software on the same host can reach it.
That assumption fails when a malicious website can induce the browser to open a WebSocket to that same local endpoint. The browser is a trusted client on the machine. From the agent’s point of view, the connection looks local. In practice, the remote page is performing server-side request forgery through the user’s own browser, using WebSocket as the transport. Once connected, the attacker may issue agent commands, read tool outputs, or steer tool use as if they sat at the keyboard.
Why Local Agents Are Exposed
Local AI agents are useful precisely because they hold privileged context: filesystem access, shell tools, browser automation, secrets in environment variables, and model APIs. To make that power usable, products often ship with minimal authentication on localhost, open CORS or origin checks that treat loopback as safe, and predictable default ports. Those choices reduce friction for legitimate clients and also reduce friction for hijack attempts.
WebSocket-based control makes the problem sharper. Unlike a one-shot HTTP call, a WebSocket session stays open, streams events, and may accept a full command protocol. If origin validation, token binding, or proof-of-possession is missing, a page the user merely visits can become a remote console for the agent. The user never “installs” malware; the browser is the bridge.
Practical Defenses
Treat every local agent control plane as internet-facing until proven otherwise. Prefer a secret token required on every connection, generated per install and never embedded in client-side page code that untrusted origins can read. Bind authentication to the WebSocket handshake, reject missing or wrong tokens before any protocol messages are accepted, and rotate tokens when compromise is suspected.
- Validate Origin (and related headers) strictly; allow only known local UIs, not arbitrary sites.
- Avoid predictable default ports without auth; require an explicit enable flag for remote-style access.
- Scope agent tools tightly: least privilege for shell, filesystem, and network tools.
- Log and rate-limit control messages; alert on unexpected concurrent sessions.
- Keep the agent offline or paused when browsing untrusted content with high privileges active.
Architecture also matters. Separate the model runtime from a thin authenticated gateway, and put irreversible actions behind human confirmation. If a compromised session can only draft actions while sensitive steps need explicit approval, the blast radius of a hijack drops sharply.
What Developers and Users Should Do Now
If you run a local agent, assume a malicious tab can try to open its WebSocket. Inventory which processes listen on loopback, which ports they use, and whether any page on the open web could complete a handshake. Disable unused local servers. Prefer agents that document origin policy, require install-time secrets, and fail closed when auth is absent.
For builders shipping local agents, ClawJacked is a reminder that “localhost only” is not an access-control model. Design the control channel as you would a production API: authenticate, authorize, audit, and minimize default power. Users should update agent software promptly, review tool permissions after each update, and treat unexpected agent activity as a possible remote session until proven otherwise.