ClawJacked: How a Single WebSocket Flaw Gave Attackers Full Control of AI Developer Agents

A developer visits a blog post. In the background, JavaScript on that page opens a WebSocket connection to localhost:3000, brute-forces a gateway password with no rate limiting, silently registers as a trusted device, and takes full control of the AI agent running on their machine. From there, the attacker reads their Slack messages, accesses their Google Drive, sends emails from their Gmail, and exfiltrates code from private repositories.

That's not a theoretical attack. That's the ClawJacked vulnerability, disclosed on February 28, 2026 by Oasis Security, affecting every version of OpenClaw prior to 2026.2.25. OpenClaw patched it within 24 hours of responsible disclosure. But the implications extend far beyond one tool.

I've been writing about AI agent liability and the practical mechanics of AI coding assistants for a while now. ClawJacked is the kind of vulnerability that connects both threads. It's not just a bug. It's a structural warning about how we're building AI development tools and the security assumptions we're making along the way.

How the Attack Works

OpenClaw, like many modern AI agents, runs a local WebSocket gateway on your machine. This gateway is the bridge between the agent's capabilities and the services it connects to - your Slack workspace, Gmail, Google Drive, GitHub, and whatever else you've authorized.

The gateway binds to 127.0.0.1 (localhost), which most developers instinctively treat as safe. "It's only listening on my machine, so it's fine." That assumption is wrong, and ClawJacked proves it.

Here's the attack chain:

1. The victim visits any malicious or compromised website. No special permissions needed. No downloads. No phishing link clicked.
2. JavaScript on the page opens a WebSocket to localhost. Browsers don't enforce the same-origin policy on WebSocket connections the way they do for HTTP requests. Any website can open a WebSocket to your localhost without the browser blocking it.
3. The script brute-forces the gateway password. OpenClaw's gateway had no rate limiting on authentication attempts. An attacker could try thousands of passwords per second.
4. The script silently registers as a trusted device. The gateway relaxed several security mechanisms for local connections, including auto-approving new device registrations without prompting the user.
5. The attacker has full agent control. They can execute any action the agent is authorized to perform across all connected services.

The researchers at Oasis Security summarized it bluntly: "Any website you visit can open [a WebSocket] to your localhost. Unlike regular HTTP requests, the browser doesn't block these cross-origin connections."

Why "Localhost" Isn't a Security Boundary

This is the core lesson, and it goes well beyond OpenClaw.

Developers have been treating localhost as an implicit security perimeter for decades. The reasoning is intuitive: if a service only listens on 127.0.0.1, then only processes running on my machine can reach it. And since I control what runs on my machine, I control who can access the service.

That reasoning breaks in three important ways.

Browser-based attacks bypass it entirely. Your browser is a process running on your machine. Any website it loads can instruct it to make requests to localhost. For HTTP, CORS provides some protection (the server can reject cross-origin requests). For WebSockets, there's no equivalent enforcement at the protocol level. The connection just opens.

Other local processes can reach it. Malware, compromised dependencies, or even a rogue npm package running postinstall scripts can connect to any service listening on localhost. If your AI agent's gateway doesn't authenticate connections properly, anything running on your machine can control it.

Network-level isolation doesn't mean application-level security. Binding to 127.0.0.1 means the service isn't reachable from the network. It doesn't mean the service is secure. Authentication, authorization, rate limiting, and input validation are still required. ClawJacked exploited the absence of all four.

This pattern isn't unique to OpenClaw. Development tools routinely expose localhost APIs: database admin panels, hot-reload servers, debugging interfaces, API mocking tools, and now AI agent gateways. Every one of these is potential attack surface if it lacks proper authentication.

The Compliance Problem

If you're working toward SOC 2 or already certified, ClawJacked creates a direct compliance exposure.

SOC 2's Common Criteria require organizations to manage risks from software in their environment. CC6.1 covers logical access controls. CC7.1 covers identification and mitigation of vulnerabilities. CC7.2 covers monitoring of the system components. A locally-running AI agent with access to Slack, Gmail, and code repositories that can be hijacked through a browser tab isn't just a security gap. It's a control failure.

I covered the practical tooling side of this in my post on building a SOC 2 stack for under $10,000. The takeaway was that compliance doesn't require enterprise budgets, but it does require knowing what's in your environment and managing the risks. AI agents are now part of that environment, and most compliance programs haven't caught up.

Here's the specific problem: most SOC 2 control matrices focus on production infrastructure. They cover your AWS configuration, your CI/CD pipeline, your access management policies. They don't typically cover what's running on developer laptops. But ClawJacked demonstrates that a developer's local environment can be a direct path to the same data your production controls are designed to protect. If your agent has OAuth tokens for Gmail and Slack, compromising the agent compromises those services, regardless of how well your production infrastructure is locked down.

What Auditors Will Ask

If you're going through a SOC 2 audit in 2026, expect questions about AI tooling in developer environments. Here's what to prepare:

The Liability Question

Who's responsible when a developer tool gets compromised?

I explored the broader framework for this in my AI agents liability post. The answer depends on the specific facts, but the general direction is clear: vendors bear responsibility for shipping secure defaults, and deployers bear responsibility for configuring and monitoring tools appropriately.

In ClawJacked's case, the security failures were squarely on the vendor side. No rate limiting on authentication. Silent device registration for local connections. Insufficient WebSocket origin validation. These aren't configuration mistakes by users. They're architectural decisions that prioritized convenience over security.

But there's a shared-responsibility angle too. Organizations that deploy AI agents in their development environments without inventorying them, without reviewing their permissions, without including them in vulnerability management programs - they're creating their own exposure. "We didn't know our developers were running that" stopped being an acceptable answer years ago. With AI agents that have OAuth access to company Slack and Gmail, the stakes are significantly higher.

The Insurance Wrinkle

Cyber insurance policies typically cover data breaches through "computer systems" owned or operated by the insured. A locally-running AI agent is arguably part of the insured's computer system. But if the compromise vector is a third-party tool with a known vulnerability class (inadequate WebSocket security), the insurer might argue the policyholder failed to exercise reasonable care in tool selection and configuration.

This isn't hypothetical. Insurers are already asking about AI tool usage in their applications. If you can't demonstrate that you evaluated the security properties of the AI agents in your environment, you may face coverage disputes after an incident.

What to Do About It

For Individual Developers

Update OpenClaw immediately. Version 2026.2.25 patches the ClawJacked vulnerability. If you're running anything older, update now.

Audit your agent's permissions. Look at every OAuth token and API key your AI agent has access to. Apply the principle of least privilege. Does your coding assistant really need access to your Gmail? If not, revoke it.

Treat localhost services as untrusted by default. Any service listening on localhost that handles sensitive data or actions needs authentication, even for local connections. If a tool doesn't offer this, that's a red flag.

Monitor WebSocket connections. Tools like Little Snitch (macOS) or OpenSnitch (Linux) can alert you to unexpected localhost connections from your browser.

For Engineering Leaders and CTOs

Inventory all AI agents in your development environment. You can't secure what you don't know about. Survey your team, check for locally-running agents, and document their capabilities and permissions.

Include AI agent tooling in your vulnerability management program. These tools get the same treatment as any other software in your stack: tracked versions, monitored CVEs, defined patch cadence.

Review and restrict OAuth scopes. When provisioning AI agent access to company services (Slack, Gmail, Drive), use the narrowest possible scopes. Create dedicated service accounts with limited permissions rather than connecting agents to individual user accounts with broad access.

Add AI agent security to your compliance documentation. If you're SOC 2 certified, update your system description to include AI development tools. Add controls around their deployment, configuration, and monitoring.

Establish an approved-tools policy. Not every AI agent that a developer finds interesting should run on machines with access to company resources. Create a review and approval process for new AI tools, similar to your vendor security review process.

For Startup Founders

This is a board-level conversation. If your engineering team is using AI agents (and they almost certainly are), the security properties of those agents are a business risk. Make sure someone is responsible for evaluating and managing that risk.

Factor this into your SOC 2 readiness. If you're planning to get certified, AI agent security in developer environments is a gap that auditors will increasingly scrutinize. Better to address it proactively than to scramble during the audit.

Use it as a differentiator. If your competitors aren't thinking about AI agent security in their development environments (most aren't), your proactive approach becomes a selling point in security questionnaires and enterprise sales conversations.

The Bigger Picture

ClawJacked is the first high-profile vulnerability in the AI agent ecosystem, but it won't be the last. As these tools become more capable and more connected, the attack surface they create grows proportionally.

The pattern is familiar. It's the same trajectory we saw with browser extensions, CI/CD tools, and cloud infrastructure: a new category of tooling emerges, adoption outpaces security maturity, a major vulnerability forces the industry to take the risks seriously, and standards gradually catch up.

We're at step three. The question is whether the AI agent ecosystem learns from those previous cycles or repeats the same mistakes. The early signs are mixed. OpenClaw patched quickly, which is encouraging. But the fact that a tool with this level of access shipped without basic WebSocket security controls suggests that the "move fast" culture still dominates the "move securely" imperative in AI tooling.

For developers and companies adopting these tools, the message is simple: AI agents are software. Software has vulnerabilities. Treat your AI tools with the same security rigor you apply to every other component in your stack. Localhost isn't a security boundary. Convenience defaults aren't security controls. And the tools that help you write code faster are only as trustworthy as the security practices behind them.

Keep reading:

• AI Agents and Liability: Who's Responsible When the Agent Gets It Wrong?
• The Secret Sauce Isn't Better Prompts: How I Actually Use AI Coding Assistants
• The Budget SOC 2 Stack: Getting Certified for Under $10,000

Securing your AI development environment for SOC 2 or enterprise sales? Let's talk.