ClawJacked: How Any Website Could Hijack Your AI Coding Agent via WebSocket

TL;DR​‌‌​​​‌‌‍​‌‌​‌‌​​‍​‌‌​​​​‌‍​‌‌‌​‌‌‌‍​‌‌​‌​‌​‍​‌‌​​​​‌‍​‌‌​​​‌‌‍​‌‌​‌​‌‌‍​‌‌​​‌​‌‍​‌‌​​‌​​‍​​‌​‌‌​‌‍​‌‌‌​‌‌‌‍​‌‌​​‌​‌‍​‌‌​​​‌​‍​‌‌‌​​‌‌‍​‌‌​‌‌‌‌‍​‌‌​​​‌‌‍​‌‌​‌​‌‌‍​‌‌​​‌​‌‍​‌‌‌​‌​​‍​​‌​‌‌​‌‍​‌‌​‌​​​‍​‌‌​‌​​‌‍​‌‌​‌​‌​‍​‌‌​​​​‌‍​‌‌​​​‌‌‍​‌‌​‌​‌‌‍​‌‌​‌​​‌‍​‌‌​‌‌‌​‍​‌‌​​‌‌‌‍​​‌​‌‌​‌‍​‌‌​​​​‌‍​‌‌​‌​​‌‍​​‌​‌‌​‌‍​‌‌​​​‌‌‍​‌‌​‌‌‌‌‍​‌‌​​‌​​‍​‌‌​‌​​‌‍​‌‌​‌‌‌​‍​‌‌​​‌‌‌‍​​‌​‌‌​‌‍​‌‌​​​​‌‍​‌‌​​‌‌‌‍​‌‌​​‌​‌‍​‌‌​‌‌‌​‍​‌‌‌​‌​​‍​‌‌‌​​‌‌

  • A vulnerability named ClawJacked allowed any malicious website to silently take full control of a locally running OpenClaw AI agent — no plugins, no clicks, no warnings.
  • The attack exploited a browser quirk: WebSocket connections to localhost bypass cross-origin policies, letting any website open a channel directly to your local AI gateway.
  • With access, attackers could steal credentials, read message histories, list connected devices, and execute shell commands on paired machines.
  • OpenClaw patched the issue in version 2026.2.26 (released February 26, 2026). If you haven't updated, do it now.
  • This is part of a broader pattern: AI coding agents are becoming high-value targets because they sit at the intersection of developer trust, broad system access, and weak security defaults.

The Vulnerability in Plain English (ELI10 Version)

Imagine you have a really smart robot assistant living on your computer. This robot — your AI coding agent — can read your files, send messages for you, run commands, even talk to your phone. You've set it up so only you can talk to it, and you've given it a secret password.

Now imagine any random website you visit could whisper directly to your robot, try a thousand passwords in one second, figure out the right one, and then tell your robot to do whatever it wants — all while you sit there watching YouTube, completely unaware.​‌‌​​​‌‌‍​‌‌​‌‌​​‍​‌‌​​​​‌‍​‌‌‌​‌‌‌‍​‌‌​‌​‌​‍​‌‌​​​​‌‍​‌‌​​​‌‌‍​‌‌​‌​‌‌‍​‌‌​​‌​‌‍​‌‌​​‌​​‍​​‌​‌‌​‌‍​‌‌‌​‌‌‌‍​‌‌​​‌​‌‍​‌‌​​​‌​‍​‌‌‌​​‌‌‍​‌‌​‌‌‌‌‍​‌‌​​​‌‌‍​‌‌​‌​‌‌‍​‌‌​​‌​‌‍​‌‌‌​‌​​‍​​‌​‌‌​‌‍​‌‌​‌​​​‍​‌‌​‌​​‌‍​‌‌​‌​‌​‍​‌‌​​​​‌‍​‌‌​​​‌‌‍​‌‌​‌​‌‌‍​‌‌​‌​​‌‍​‌‌​‌‌‌​‍​‌‌​​‌‌‌‍​​‌​‌‌​‌‍​‌‌​​​​‌‍​‌‌​‌​​‌‍​​‌​‌‌​‌‍​‌‌​​​‌‌‍​‌‌​‌‌‌‌‍​‌‌​​‌​​‍​‌‌​‌​​‌‍​‌‌​‌‌‌​‍​‌‌​​‌‌‌‍​​‌​‌‌​‌‍​‌‌​​​​‌‍​‌‌​​‌‌‌‍​‌‌​​‌​‌‍​‌‌​‌‌‌​‍​‌‌‌​‌​​‍​‌‌‌​​‌‌

That is exactly what ClawJacked could do.

The "ClawJacked" vulnerability (discovered by researchers at Oasis Security and fixed in OpenClaw version 2026.2.26) exploited a gap between how browsers handle normal web requests versus WebSocket connections. Most browsers enforce what's called a "Same-Origin Policy" — websites can only talk to the same server they came from. But WebSockets, the technology used for real-time two-way communication, were designed with looser rules. Any website can open a WebSocket connection to localhost — your own computer — without any browser warning.

OpenClaw's local gateway was listening on localhost. The brute-force rate-limiting that was supposed to stop password guessing? It was disabled for localhost connections by design, so local tools wouldn't get locked out. Those two facts together created a catastrophic attack chain: visit a malicious site → JavaScript opens a WebSocket to your AI agent → brute-forces your password at hundreds of attempts per second → logs in → owns your entire developer environment.

What Is OpenClaw and Why Should You Care?

OpenClaw is a self-hosted AI agent platform that exploded in popularity in early 2026, reaching over 100,000 GitHub stars in its first five days. It enables AI agents to autonomously send messages, run terminal commands, manage files, and orchestrate tasks across multiple platforms — including connected phones, laptops, and cloud services.

For developers, it's an extraordinary productivity tool. For attackers, it's an extraordinary target. OpenClaw installations represent what Oasis Security calls a growing category of "shadow AI": developer-adopted tools that run outside IT security team visibility, often with broad system access, stored credentials, and no centralized governance or monitoring.

According to Oa

sis Security's disclosure report, OpenClaw's gateway is a local WebSocket server that acts as the "brain" of the operation — handling authentication, managing chat sessions, storing configuration, and dispatching commands to connected "nodes" (your phone, other machines, companion apps). The gateway can instruct any connected node to run shell commands, read contacts, access the camera, and more. Compromise the gateway, and you own the entire device mesh.

How the ClawJacked Attack Works: The Technical Chain

Oasis Security's researchers decomposed the ClawJacked attack into four steps, each building on the previous one [1].

Step 1 — The Victim Visits a Malicious Website

The attacker controls a website — or has compromised a legitimate one. The victim is a developer with OpenClaw running on their laptop. No special interaction required: just opening the browser tab triggers the attack.

Step 2 — JavaScript Opens a Localhost WebSocket

Browser-side JavaScript silently opens a WebSocket connection to ws://127.0.0.1:<gateway_port>. According to researchers, this works because browsers do not apply the Same-Origin Policy to WebSocket connections to localhost in the way they do to HTTP/HTTPS requests [2]. The browser does include an Origin header in the WebSocket handshake, but OpenClaw's gateway was not validating it.

Step 3 — Brute-Force Authentication at Scale

OpenClaw includes rate limiting to prevent password brute-forcing. However, connections from the loopback address (127.0.0.1) were explicitly exempted — the intention was to avoid locking out legitimate local CLI sessions. The researchers found they could attempt hundreds of password guesses per second directly from browser JavaScript, with no throttling and no logging of failed attempts.

"In our lab testing, we achieved a sustained rate of hundreds of password guesses per second from browser JavaScript alone. At that speed, a list of common passwords is exhausted in under a second, and a large dictionary would take only minutes. A human-chosen password doesn't stand a chance." — Oasis Security [1]

Step 4 — Silent Device Pairing and Full Takeover

Once the correct password was found, the attacker could register as a trusted device. OpenClaw's gateway automatically approves device pairings from localhost without requiring user confirmation. With an authenticated admin session, the attacker could then interact directly with the AI agent: dump stored credentials, enumerate connected nodes, read application and conversation logs, instruct the agent to search messaging histories, exfiltrate files from connected devices, or execute arbitrary shell commands on paired machines — resulting in full workstation compromise triggered from a browser tab.

Why WebSocket Hijacking Is Such a Hard Problem

Cross-Site WebSocket Hijacking (CSWSH) is not a new attack class. OWASP's WebSocket Security Cheat Sheet [3] has documented the risk for years: because WebSocket handshakes don't benefit from the same automatic CORS enforcement as HTTP requests, servers must explicitly validate the Origin header on every incoming WebSocket connection. Most developers know to do this for remote servers. Almost nobody thinks about it for localhost.

The localhost assumption is the killer. Developers instinctively trust that "localhost means only my machine," but browsers allow any page you load — regardless of origin — to make connections to your own loopback interface. This isn't a browser bug; it's a documented design decision. The WebSocket RFC (RFC 6455) [4] specifies that servers are responsible for origin validation. When running a local service, that validation is often skipped because developers assume no remote party could reach it.

According to PortSwigger's Web Security Academy documentation on CSWSH [5]: "The attacker's page can perform WebSocket interactions with the vulnerable application. If the application uses session cookies for authentication of WebSocket connections, and does not perform CSRF token or similar protections, the attacker can gain full two-way interaction with the application." For local services that use password authentication, the attack surface is actually worse — attackers can brute-force credentials in-band, not just piggyback existing sessions.

The compounding factor in ClawJacked was the rate-limit exemption for loopback connections. Security engineers often create explicit carve-outs for localhost to improve developer experience. ClawJacked illustrates exactly how those carve-outs become exploitable assumptions.

The Broader Pattern: AI Coding Agents Are the New Attack Surface

ClawJacked is not an isolated incident. It's a data point in an accelerating trend: AI coding agents and developer tools are becoming primary targets for sophisticated attackers, for three structural reasons.

1. They have enormous access by design. AI coding agents like OpenClaw, Claude Code, GitHub Copilot Workspace, and similar tools need access to files, terminals, APIs, and credentials to be useful. That access makes them extraordinarily valuable to compromise. A single hijacked agent can exfiltrate entire codebases, inject backdoors, steal API keys, and pivot to cloud infrastructure — all through legitimate, authenticated channels.

2. They live outside security team visibility. According to Obsidian Security's 2025 AI Agent Security Landscape report [6], in 2025 attackers hijacked a chat agent integration to breach 700+ organizations in one of the largest SaaS supply chain security breaches in history. Many of those organizations didn't know the agent existed. Developer-adopted tools routinely bypass procurement, security review, and monitoring processes.

3. The marketplace attack surface is exploding. Just two weeks before ClawJacked's disclosure, researchers discovered over 1,000 malicious skills in OpenClaw's community marketplace (ClawHub) — fake plugins masquerading as cryptocurrency tools and productivity integrations that deployed info-stealers and backdoors [1]. These are two distinct attack vectors: supply-chain poisoning through the plugin ecosystem, and core protocol exploitation like ClawJacked. Both are active. Both are being exploited.

NIST's AI Risk Management Framework (AI RMF 1.0) [7] explicitly calls out the AI supply chain as a trust boundary requiring dedicated controls. The framework's GOVERN and MANAGE functions require organizations to extend their supply chain diligence to AI tools, covering data provenance, tool integrity, and runtime behavior monitoring — not just the models themselves, but the entire agent infrastructure stack.

The Federal Register's January 2026 Request for Information on AI Agent Security [8] noted that security considerations for AI agents are evolving rapidly, and that existing frameworks do not fully address the novel risk surface created by autonomous agents with persistent access to production systems. That gap is where ClawJacked lives.

What OpenClaw Fixed (and What It Means for Other Tools)

OpenClaw's maintainers shipped a fix within 24 hours of Oasis Security's disclosure, releasing version 2026.2.26 on February 26, 2026. The patch addressed three things:

  1. Origin header validation on WebSocket handshake — the gateway now rejects WebSocket connections from origins it doesn't recognize, regardless of whether the connection is from localhost.
  2. Rate limiting on loopback connections — the localhost exemption for brute-force protection was removed. Local CLI sessions now receive the same throttling as remote connections.
  3. Explicit logging of failed authentication attempts from all origins — including loopback, previously invisible in logs.

This is a textbook example of well-handled disclosure: researchers found it, reported it responsibly, the vendor fixed it fast, and both parties published detailed technical documentation. That transparency is how the broader ecosystem learns.

But the lesson extends beyond OpenClaw. Any locally hosted service that:

  • Exposes a WebSocket interface
  • Assumes localhost connections are trusted
  • Exempts loopback addresses from authentication controls

...is potentially vulnerable to the same class of attack. If your team is running any local AI tooling — LLM proxies, agent frameworks, developer dashboards, local API gateways — this is the moment to audit them.

Practical Defense Steps for Teams Using AI Coding Agents

The following controls address ClawJacked-style attacks and the broader class of local service hijacking vulnerabilities. They're ordered from immediate tactical action to longer-term strategic posture.

Immediate Actions (Do These Today)

Update OpenClaw to version 2026.2.26 or later. If your team uses OpenClaw, this is non-negotiable. The vulnerability is fully disclosed, proof-of-concept code exists, and attackers will be actively exploiting unpatched installations.

Audit all locally running services for WebSocket exposure. Run ss -tlnp | grep -E '127.0.0.1|0.0.0.0' and lsof -i -P -n | grep LISTEN to enumerate listening services. For each WebSocket-capable service, verify that Origin header validation is enabled. According to the OWASP WebSocket Security Cheat Sheet [3], servers must validate the Origin header during the WebSocket handshake and reject connections from unexpected origins.

Inventory your team's AI tooling. If individual developers are running AI agents, you need to know. Shadow AI is a real risk. Create a lightweight inventory: what tools, what versions, what access do they have?

Medium-Term Controls

Enforce rate limiting on all local services without loopback exemptions. The ClawJacked attack succeeded specifically because localhost was exempt from rate limiting. Don't create that carve-out. If local CLI tools get locked out, implement explicit allowlisting by process or token, not by network address.

Use strong, randomly generated tokens instead of human-chosen passwords for local service authentication. Human-chosen passwords are brute-forceable in under a second at hundreds of attempts/second. A 256-bit random token is not. Most AI agent frameworks support token-based authentication — use it.

Isolate AI agent network access with host-based firewall rules. Restrict which processes and interfaces your AI agent gateway can listen on. Consider binding to a Tailscale or VPN interface only, rather than localhost, if your threat model permits it. This trades convenience for a substantially higher attack bar.

Monitor AI agent logs for anomalous activity. If an attacker is brute-forcing your gateway, it should appear in logs. Ensure logging is enabled, failed authentication attempts are captured, and those logs feed into your SIEM or alerting pipeline.

Strategic Posture

Treat AI coding agents as privileged infrastructure, not developer toys. If a tool can execute shell commands, read credentials, and talk to your phone — it's privileged infrastructure. Apply the same review, monitoring, and access-control processes you'd apply to a privileged access workstation.

Apply NIST AI RMF GOVERN controls to your AI tool stack. NIST AI RMF 1.0 [7] recommends establishing organizational accountability for AI systems in use, including developer tooling. This doesn't require a PhD in AI governance — it means knowing what AI tools are deployed, who owns them, and what access they have.

Adopt the principle of least privilege for agent capabilities. AI agents should have access to exactly what they need for their task, and nothing more. If your coding agent doesn't need camera access or the ability to execute arbitrary shell commands, disable those capabilities.

The Self-Hosting Security Tradeoff

ClawJacked highlights a genuine tension in the AI agent ecosystem. Self-hosted tools like OpenClaw are attractive precisely because they keep your data local — no cloud service, no data leaving your machine. That's a real privacy and security benefit. But self-hosting means you own the security posture entirely. There's no SaaS vendor hardening the perimeter for you. Every locally running service is a potential attack surface that you are responsible for.

This doesn't mean self-hosting is wrong. It means it requires the same security rigor as any internet-facing service. Local doesn't mean safe. If a browser tab can reach it, an attacker can reach it.

The risk calculus for teams adopting AI coding agents should include: what is this tool's default security posture? What permissions does it require? What happens if it's compromised? Does the vendor have a responsible disclosure process and a track record of fast patching? OpenClaw, despite this vulnerability, demonstrated exactly the right response: transparent disclosure, fast patch, detailed documentation. That matters.

FAQ: ClawJacked and AI Agent Security

Q: What is the ClawJacked vulnerability, exactly?

ClawJacked is a high-severity vulnerability in OpenClaw, a self-hosted AI agent platform, that allowed any malicious website to silently take full control of a locally running OpenClaw instance. The attack exploited the fact that browser WebSocket connections to localhost bypass cross-origin policies, combined with an OpenClaw configuration that exempted loopback connections from brute-force rate limiting. Discovered by Oasis Security, the flaw was patched in OpenClaw version 2026.2.26.

Q: Do I need to have clicked something or installed anything for this attack to work?

No. The attack required only that the victim visit a malicious (or compromised) website while OpenClaw was running on their machine. No plugins, browser extensions, or user interaction beyond visiting the page were required. This is what makes it particularly dangerous — there is no obvious action to avoid.

Q: Is this specific to OpenClaw, or could other AI agents be vulnerable?

The underlying vulnerability class — cross-site WebSocket hijacking against localhost services — is not specific to OpenClaw. Any locally running service that exposes a WebSocket interface, doesn't validate the Origin header, and treats loopback connections as implicitly trusted could be vulnerable to a similar attack. Teams should audit all locally running AI tooling and developer services for these properties.

Q: We use a commercial AI coding assistant (GitHub Copilot, Cursor, etc.), not OpenClaw. Are we affected?

Commercial hosted AI assistants that connect to cloud services rather than running a local WebSocket gateway are not directly affected by ClawJacked. However, many commercial tools do run local components (browser extensions, VS Code extensions, local proxies) that could have similar attack surfaces. The principle of auditing locally running services applies regardless of vendor.

Q: How do we know if our OpenClaw installation has already been compromised?

Review your OpenClaw gateway logs for unexpected device pairings, authentication attempts (especially failed ones prior to a successful login), and unusual agent activity (unexpected commands executed, credential lookups, file access). If your version was below 2026.2.26 and logs show unusual activity, treat the installation as potentially compromised: rotate all credentials stored in or accessible by the agent, review what files were accessible to connected nodes, and consider a full workstation forensic review.

Q: What's the CVE identifier for ClawJacked?

As of this writing, the ClawJacked vulnerability does not have a publicly assigned CVE identifier. Oasis Security's advisory and OpenClaw's release notes for version 2026.2.26 are the authoritative references. Monitor the OpenClaw GitHub repository and Oasis Security's blog for updates.

TL;DR

  • TL;DR > - A vulnerability named ClawJacked allowed any malicious website to silently take full control of a lo

    • The attack exploited a browser quirk: WebSocket connections to localhost bypass cross-origin policies, letting a
  • Action required — see the post for details

    • References

    [1] Oasis Security, "ClawJacked: OpenClaw Vulnerability Enables Full Agent Takeover," Oasis Security Blog, Feb. 2026. [Online]. Available: https://www.oasis.security/blog/openclaw-vulnerability

    [2] I. Fette and A. Melnikov, "The WebSocket Protocol," Internet Engineering Task Force (IETF), RFC 6455, Dec. 2011. [Online]. Available: https://datatracker.ietf.org/doc/html/rfc6455

    [3] OWASP Foundation, "WebSocket Security Cheat Sheet," OWASP Cheat Sheet Series. [Online]. Available: https://cheatsheetseries.owasp.org/cheatsheets/WebSocket_Security_Cheat_Sheet.html

    [4] PortSwigger Research, "Cross-site WebSocket hijacking," PortSwigger Web Security Academy. [Online]. Available: https://portswigger.net/web-security/websockets/cross-site-websocket-hijacking

    [5] C. Schneider, "Cross-Site WebSocket Hijacking (CSWSH)," Blackhat Presentation, 2013. [Online]. Available: https://www.christian-schneider.net/CrossSiteWebSocketHijacking.html

    [6] Obsidian Security, "The 2025 AI Agent Security Landscape: Players, Trends, and Risks," Obsidian Security Blog, Jan. 2026. [Online]. Available: https://www.obsidiansecurity.com/blog/ai-agent-market-landscape

    [7] National Institute of Standards and Technology (NIST), "Artificial Intelligence Risk Management Framework (AI RMF 1.0)," NIST AI 100-1, Jan. 2023. [Online]. Available: https://doi.org/10.6028/NIST.AI.100-1

    [8] Office of Management and Budget / NIST, "Request for Information Regarding Security Considerations for Artificial Intelligence Agents," Federal Register, Vol. 91, No. 5, Jan. 8, 2026. [Online]. Available: https://www.federalregister.gov/documents/2026/01/08/2026-00206/request-for-information-regarding-security-considerations-for-artificial-intelligence-agents

    [9] BleepingComputer, "ClawJacked attack let malicious websites hijack OpenClaw to steal data," BleepingComputer Security News, Mar. 2026. [Online]. Available: https://www.bleepingcomputer.com/news/security/clawjacked-attack-let-malicious-websites-hijack-openclaw-to-steal-data/

    [10] National Institute of Standards and Technology (NIST), "Cybersecurity Framework Profile for Artificial Intelligence (Cyber AI Profile)," NIST IR 8596 iprd, Dec. 2025. [Online]. Available: https://nvlpubs.nist.gov/nistpubs/ir/2025/NIST.IR.8596.iprd.pdf

    Is Your Team's AI Tooling a Security Risk?

    ClawJacked is a wake-up call. AI coding agents are becoming core developer infrastructure — and most security teams haven't caught up with the risk. If your developers are running AI agents with access to production systems, credentials, and internal tooling, the question isn't whether you have exposure. It's whether you know what it looks like.

    lil.business helps small teams and growing companies get ahead of exactly this kind of risk — practical, no-fluff security consulting that works with how developers actually work.

    👉 Book a free consultation — we'll walk through your AI tool stack, identify your actual exposure, and give you a prioritized action plan. No jargon, no 200-page reports. Just what matters.

    consult.lil.business →

    Ready to strengthen your security?

    Talk to lilMONSTER. We assess your risks, build the tools, and stay with you after the engagement ends. No clipboard-and-leave consulting.

    Get a Free Consultation