ClawJacked: any website could hijack your OpenClaw agent

By Linas Valiukas · May 1, 2026

Visit one bad website. Lose your agent. That was the deal ClawJacked offered, and it sat in OpenClaw's gateway for an unknown number of months before Oasis Security disclosed it on February 26, 2026. No phishing email. No malicious skill. No exposed port. You just had to be browsing a normal tab while OpenClaw was running on your laptop.

Oasis told the OpenClaw maintainers, the maintainers shipped a patch in 24 hours, and the news bounced through The Hacker News, BleepingComputer, Security Affairs, and CSO Online over the next week. We covered it briefly inside the 9 CVEs in 4 days roundup. It deserved its own piece, because the bug isn't really about a missing rate limiter. It's about a category of trust assumption that's still baked into half the agent stack you're running.

What ClawJacked actually is

Tracked as CVE-2026-32025. CVSS 8.8 (High). Affects every OpenClaw build before v2026.2.25. The fix landed February 26, 2026, the same day the disclosure went public.

The short version: a malicious web page in any tab of your browser could silently take over your locally running OpenClaw gateway. Not "find a way in eventually." Not "with user interaction." Open the tab, the JavaScript starts running, and within a few minutes the page has admin on your agent. No clicks. No prompts. No notifications.

Oasis dubbed it ClawJacked. They published a detailed writeup with proof-of-concept code, then sat on it long enough for the maintainers to push the patch and a stable release. ThreatIntelReport's writeup calls it a "chain" rather than a single bug, and that's the right framing. Four small design decisions stacked into a full takeover.

The four trust assumptions that stacked

Each piece, on its own, looked reasonable. Together they handed the keys over.

1. WebSockets to localhost aren't blocked by Same-Origin Policy

This is a browser fact, not an OpenClaw bug. If a normal HTTP request from https://attacker.example tries to read http://localhost:3210/api/secret, CORS stops it from reading the response. WebSockets play by different rules. The handshake is allowed across origins, and once the socket is open, the page can send and receive arbitrary frames. Browsers have known this since at least 2015, and it's why localhost services that talk WebSocket need to validate the Origin header themselves. OpenClaw's gateway didn't.

2. The rate limiter exempted 127.0.0.1

OpenClaw's gateway has login rate limiting. It would refuse repeated bad password attempts from any external IP. Local CLI tools and admin scripts hit the same login flow, and the maintainers didn't want a runaway script to lock the user out of their own machine. So the loopback address got exempted. Failed login attempts from 127.0.0.1 weren't throttled and weren't logged.

Oasis demonstrated that this exemption let them try hundreds of passwords per second from a browser tab. A six-character ACCESS_CODE that would take centuries to brute-force from the public internet falls in minutes when you can guess freely. Most users don't set long ACCESS_CODEs because they're typing them on their own laptop and short feels fine. The threat model assumed external attackers. ClawJacked changed who counts as "external."

3. Localhost device pairings auto-approved

When a new phone, browser, or CLI tool tries to pair with your OpenClaw gateway, the dashboard normally pops up a "trust this device?" prompt. The user clicks yes, the device gets added to the trusted list, and from then on it talks to the gateway without re-prompting.

For local connections, the gateway skipped the prompt. Reasoning was the same as the rate limiter exemption: if you're already on the same machine, you're already trusted. So the malicious tab finishes its brute force, opens an authenticated session, registers a new "trusted device," and from then on doesn't even need to brute-force again. Persistence acquired.

4. Trusted devices got admin scope by default

Once paired, the device session inherited the user's full permissions. There was no read-only flow, no per-skill capability gate, no "minimum scope" for a freshly registered device. The browser tab was now indistinguishable from the user's own laptop dashboard. It could read every conversation, install skills, change provider keys, run arbitrary tool calls, and pull files off disk through any skill that exposed file access.

Oasis's disclosure shows the post-pairing actions explicitly: dump credentials, list connected nodes, read application logs, push messages through Telegram and WhatsApp bridges. Everything the user could do, the malicious tab could do.

The end-to-end attack, step by step

Walk through what actually happened on a victim machine. The whole chain runs from a single tab, with no user action beyond visiting the page.

1. Victim is running OpenClaw locally on their laptop. Gateway listens on ws://127.0.0.1:3210. ACCESS_CODE is set to something like openclaw or password123. Most defaults you find in a quick-start tutorial.
2. Victim opens any tab - a Reddit thread, a news article, a search result. The page loads JavaScript that fingerprints the OS and tries common OpenClaw gateway ports.
3. The JS opens new WebSocket("ws://127.0.0.1:3210/auth"). The browser allows the cross-origin handshake. The gateway accepts it and asks for the password.
4. The script starts firing password guesses at hundreds per second. Top 1,000 weak passwords first, then a small dictionary, then the user's likely first names and birth-year combos pulled from a separate fingerprint signal. The gateway throttles nothing, logs nothing.
5. Within a few minutes, a guess lands. The script gets back a session token.
6. The script registers a new device pairing. The gateway, seeing the request originate from 127.0.0.1, auto-approves. No dashboard prompt. The user, if they have the dashboard open at all, sees nothing.
7. The script now has a stable trusted session. It walks the API: list connected providers, dump API keys from the configuration store, list installed skills, list recent conversations, list connected channels. Optionally it sends a message through Telegram or WhatsApp masquerading as the user. Optionally it installs a skill that establishes outbound persistence.
8. The user closes the tab. The brute force ends. The trusted device pairing persists. The skill install persists. The exfiltrated keys persist on the attacker's server.

What an attacker can do with a hijacked gateway

The point of an agent is that it can do things on your behalf. Once the gateway is compromised, the blast radius is the union of every integration you've connected.

• Provider keys. Anthropic, OpenAI, Google, Groq, OpenRouter, Z.AI - whatever you've configured. BleepingComputer's writeup confirms keys are stored in cleartext in the gateway config and accessible via the same API a paired device uses. Expect a surprise bill.
• Conversation history. Every chat, with every messaging integration. Personal stuff, work stuff, anything you ever pasted into a session for the agent to "help with."
• OAuth tokens. Telegram bot tokens. WhatsApp Business credentials. GitHub fine-grained PATs. Google Calendar refresh tokens. The gateway needs them to do its job. The hijacker now has them.
• Outbound messaging as you. Send to your contacts, in your voice. Phishing-as-the-user is the obvious next step.
• Skill installs. The hijacker can drop a malicious skill. From there, refer to the ClawHub malware writeup. Crypto stealers, prompt injection, persistence.
• Filesystem access. If you've enabled any skill with disk read or write (and most useful skills do), the agent can be told to pull ~/.ssh/id_rsa, .env files, browser password databases, or anything else under your user account.

The 24-hour patch and what it actually changed

Credit where it's due. Oasis disclosed Thursday morning, the OpenClaw maintainers shipped v2026.2.25 Thursday night. TechBriefly's writeup documents the timeline. The release notes are short and the diff is small.

• Rate limiting now applies to 127.0.0.1 and ::1. Failed login attempts from loopback are throttled and logged.
• The gateway validates the WebSocket Origin header on the auth endpoint. Browser-originated connections from arbitrary domains get rejected at the handshake.
• Localhost device pairings now show the trust prompt in the dashboard. The auto-approve path is removed.
• New paired devices start with a "needs admin promotion" scope. Read-only by default until you click promote.

Each individual change is correct. Each one is also a bandage on a deeper assumption: that "running on the same machine" maps to "trusted by the user." That assumption was wrong before ClawJacked, it's still wrong now, and the next bug in the same family is somewhere in the desktop IPC channel or the plugin runtime.

How to check if you were exposed before the patch

If you ran any pre-2026.2.25 build with a normal browser open on the same machine, treat it as compromised until proven otherwise. There's no telemetry that confirms a specific hit, because the failed attempts weren't logged. Run through this list anyway:

1. List paired devices. Open the gateway dashboard, go to Devices or Sessions. Anything you don't recognize, especially anything created during your unpatched window, is a red flag. Revoke it.
2. Rotate every key the gateway touched. Anthropic console, OpenAI dashboard, Google AI Studio, OpenRouter, Groq, Z.AI - revoke and re-issue. Same for Telegram bot tokens, WhatsApp credentials, GitHub PATs, anything else you'd configured.
3. Check provider billing. Anthropic and OpenAI both show usage by API key with timestamps. Look for spikes during the unpatched window from clients you don't run.
4. List installed skills. Anything you don't remember installing, uninstall it. Cross-check against the ClawHub issues tracker for known malicious entries.
5. Audit recent conversations. Look for sessions you didn't start. Look for skills running tool calls you didn't request. The hijacker would likely cover their tracks, but cheap operators don't.
6. Check network logs. If you have any kind of outbound logging - Little Snitch, OpenSnitch, pfSense, a corporate proxy - look at outbound connections from the OpenClaw process during your unpatched window. Anything to a destination you don't recognize is worth investigating.

If you're a more methodical type, the OpenClaw security hardening guide covers the post-incident lockdown checklist in detail.

Why this isn't the last bug of its kind

"Localhost is trusted" runs through more than the gateway. The desktop app's IPC channel between renderer and main process makes the same assumption. The plugin sandbox grants extra capabilities to plugins that talk to it locally. The Matrix bridge, the voice-call bridge, the Codex provider proxy - each one has its own surface where the trust boundary blurs into "we're on the same machine, we must be the same person."

The 9 CVEs that landed three weeks later included CVE-2026-22172, a self-declared admin scope bug in the same WebSocket layer ClawJacked exploited. Different bug, same neighborhood. Israeli Tech Radar made the broader point well: the autonomous-agent category is shipping faster than the security model is catching up. Every time you wire a new tool to your agent, you've extended the blast radius of every gateway bug for free.

The architectural fix isn't tighter validation on each new endpoint. It's a default that the agent's gateway speaks only to processes it can authenticate cryptographically, with no special privileges granted to "same machine." That's a real refactor, not a patch. Until it lands, expect more.

What to do this week

Three things, in this order:

1. Update. Anything older than the latest stable is a bad idea, but the floor for ClawJacked specifically is v2026.2.25. The current stable as of this post is v2026.4.29, with caveats from the update treadmill.
2. Rotate. Every credential the gateway has ever held. Don't try to figure out which ones the hijacker actually grabbed - that's not a winnable investigation.
3. Lock down the trust boundary. Set a long ACCESS_CODE. Bind the gateway to 127.0.0.1 only. Block outbound traffic from the OpenClaw process to anything outside your provider list. Treat the dashboard as if it's reachable from the internet, even when it's not.

Or, you know, run the agent somewhere it isn't sharing a process tree with your browser. Managed instances at TryOpenClaw.ai patched ClawJacked for everyone before most self-hosters had finished reading the disclosure. The trust boundary on a managed gateway doesn't include your browser tabs, because your browser isn't on the same box. We'd rather be talking about agent capabilities than CVE counts. We're going to be talking about CVE counts for a while yet.