← Intel
ClawJacked: When Your Browser Hands the Keys to Your Agent
agent-securitywebsocketopenclawbrowser-hijackcve

ClawJacked: When Your Browser Hands the Keys to Your Agent

Oasis Security demonstrated that a malicious website can silently hijack an OpenClaw agent over WebSocket, gaining full shell and API access with zero user interaction. This is the localhost trust problem, and it's not new — but agents make it catastrophically worse.

Ofir Stein·March 3, 2026note

The attack is conceptually simple, which is what makes it embarrassing: a malicious website opens a WebSocket connection to localhost, grabs the OpenClaw gateway token from the handshake, and from that point owns your agent — shell, API keys, outbound messaging, all of it. No extension. No prompt. No click. Just a browser tab you opened.

Oasis Security named it ClawJacked. Endor Labs piled on with 7 CVEs in the same disclosure cycle. That's not a coincidence — that's what happens when a product ships fast into a high-privilege environment without a threat model that accounts for browser-adjacent attack surfaces.

Here's what I keep coming back to: this isn't a novel class of vulnerability. The browser-to-localhost WebSocket attack has existed for years. Developers have been warned about it in the context of local dev servers, debuggers, and wallet daemons. The difference now is what's listening on localhost. A webpack dev server leaking source maps is annoying. An agent with shell access, credential stores, and the ability to send messages on your behalf is a different tier of impact entirely.

The "no user interaction required" part is the headline. But the deeper issue is that agentic tools are being deployed with the same security posture as local utilities — trusted by default, wide open to anything that can reach the loopback interface. That model is broken the moment you integrate a powerful capability layer.

A few things stand out as immediately actionable from this disclosure:

First, gateway tokens need origin validation. If your agent's WebSocket server accepts connections from arbitrary browser origins, you have this bug or a close cousin of it. Second, localhost is not a security boundary — it never was, but we need to stop treating it as one in agent architectures. Third, the CVE batch from Endor suggests this wasn't an isolated finding but a systemic review gap.

Concrete action: If you're running any agent with a WebSocket interface on localhost, audit your origin allowlist today. If you don't have one, that's your answer.