In late February 2026, security researchers publicly disclosed a critical vulnerability in OpenClaw, a rapidly adopted open source AI agent runtime, that allows any website a developer visits to silently hijack their locally running AI assistant—with no user interaction, plugins, or extensions required.
This flaw—informally dubbed “ClawJacked”—highlights how autonomous local AI tooling, when designed with implicit trust assumptions, can expose surprisingly powerful remote exploit vectors.
What Is OpenClaw? (Quick Technical Primer)
OpenClaw is an open-source autonomous AI agent framework that developers run locally on laptops, servers, or VMs. It is capable of:
- connecting to messaging apps, email, calendars, version control systems, etc.
- executing commands on behalf of the user
- automating workflows and integrating with external services
Unlike a simple chatbot, it maintains a persistent local “gateway” service and associated nodes that collaborate to carry out AI-driven actions.
The Vulnerability Overview
Oasis Security’s disclosure found a vulnerability chain in the OpenClaw core, independent of plugins or skill extensions, that allows a malicious external website to take over a developer’s AI agent.
Root Design Assumption
At its core, OpenClaw runs a local WebSocket gateway bound to localhost, using a password or token for authentication. This gateway coordinates message traffic, configuration, nodes, and credentials.
The critical design flaw is the assumption that:
WebSocket connections from
localhostare inherently trusted and can be automatically approved without user verification.
This led to two specific weaknesses:
- No rate limit on password guesses from localhost connections, meaning an attacker can brute-force the local gateway password in seconds.
- Automatic device pairing/approval for localhost traffic, so once authenticated the script is trusted immediately.
Attack Chain: “ClawJacked” Explained
Here is how a malicious site can trigger the compromise:
- Victim browses a malicious or compromised website in their browser.
- JavaScript on that page opens a WebSocket connection to
localhost:<OpenClaw port>. - Because browsers do not block localhost WebSockets via CORS, this connection goes through.
- The script proceeds to brute-force the OpenClaw gateway password at hundreds of attempts per second.
- The gateway’s rate limiter mistakenly exempts localhost connections, so no throttling or blocking occurs.
- Once the correct password is guessed, the script is authenticated with full admin-level rights.
- From there, the attacker’s code can interact with OpenClaw’s API, dump configuration, enumerate connected nodes, access sensitive credentials, or command the agent to execute arbitrary tasks.
Why This Matters Technically
This isn’t just another “cross-site script” problem. It is the intersection of several subtle technical issues:
1. Localhost Trust Model
Most systems assume localhost traffic is safe. But browsers flatten cross-origin restrictions for localhost, enabling any website to send WebSocket frames to a local service.
2. Rate Limiting Policy Bypass
A password protection is only as strong as its enforcement mechanism. Here, exempting localhost from throttling effectively nullifies the protection.
3. Persistent Credentials and Agent Autonomy
OpenClaw agents often hold long-lived credentials that grant access to email, chat, cloud services, and internal APIs. Taking control of the agent is thus equivalent to compromising a developer’s secure environment.
This shows how insecure defaults in autonomous local agents expose an unexpected attack surface: trusted local APIs reachable from the web browser with minimal isolation.
Responsible Disclosure and Remediation
Once disclosed the issue to the OpenClaw team, a fix was issued within 24 hours, and users were advised to update to version 2026.2.25 or later immediately.
Technical Mitigations and Defense-In-Depth
With autonomous agent platforms gaining traction, organizations should consider the following defensive measures:
1. Isolation and Containment
Run self-hosted agents inside isolated environments—such as dedicated VMs, containers with restricted networking, or separate physical hosts—to prevent browser-initiated local connections from being trusted.
2. Proper Rate Limiting and Authentication
Enforce rate limits globally—not just based on source—especially for local interfaces. Consider multi-factor authentication or trust tokens that cannot be brute-forced via script.
3. Credential Governance
Treat agent credentials as first-class identities subject to regular rotation, least privilege, and monitoring. AI agents with persistent credentials should be audited like service accounts.
4. Transparent Logs and Alerts
Ensure that all access attempts to local agent gateways generate logs and alerts visible to defenders. Silent approvals and background connections should be surfaced.
5. Governance for AI Agents
Establish policy controls that govern whether developers can deploy autonomous agents, what capabilities they can receive, and how their actions are audited within broader identity security frameworks.
Conclusion
The OpenClaw “ClawJacked” vulnerability is a stark reminder that powerful autonomous AI agents—especially fully local ones with broad permissions—can dramatically expand an organization’s threat surface when foundational trust assumptions are not well scrutinized.
As autonomous agent runtimes take on more responsibilities, security architects must rethink how local processes and AI identities are managed, authenticated, and monitored. Effective defense relies not just on patching software bugs, but on architectural design that anticipates how browsers, local services, and extended identity surfaces interact under adversarial conditions.
