Oasis Security researchers disclosed a vulnerability chain that they said allowed a malicious website to take over a locally running OpenClaw AI agent, exposing how browser-accessible local services can become a new attack surface for developers and IT teams.
The chain, dubbed ClawJacked, required no browser extension, plugin, or user approval prompt, according to Oasis. Instead, the attack relied on the way OpenClaw’s local gateway handled connections from localhost, combined with the fact that modern browsers can initiate WebSocket connections to services running on the same machine.
The finding matters because more AI tools now rely on local services that connect browser interfaces, models, APIs, and other applications, making those gateways useful control points and, if misconfigured, attractive targets.
OpenClaw said the project drew 2 million visitors in a single week, underscoring how quickly it has gained attention. Oasis said OpenClaw uses a local gateway to manage authentication, store configuration, and coordinate activity across connected nodes. In its default setup, the gateway listens on localhost, a design choice often treated as safer than exposing a service to the wider network.
How the Attack Worked
Oasis said a victim only needed to be running OpenClaw locally and to visit a malicious or compromised website. JavaScript on that page could then open a WebSocket connection to the OpenClaw gateway over localhost, with no visible prompt to the user.
From there, the attack targeted the gateway password. The gateway’s rate limiting did not apply to localhost connections, Oasis said, allowing password guesses at high speed. Failed attempts were not throttled or logged, enabling brute-force attempts against the local service.
Once the password was guessed, the gateway treated the attacker as a trusted local client and automatically approved device-pairing requests from localhost, again without user confirmation. That gave the attacker what the researchers described as a fully authenticated administrative session.
In practice, Oasis said, that level of access enabled a full takeover of the AI agent. An attacker could send prompts, receive responses, access configuration data, enumerate connected devices, and review logs showing how the agent had been used and what systems it could reach.
Disclosure and Patch
Oasis said it reported the issue to the OpenClaw team through a coordinated disclosure process. OpenClaw classified the flaw as high severity and released a fix within 24 hours, according to Oasis. The researchers urged users to upgrade to version 2026.2.25 or later.
The patch closes this specific attack chain, but the incident also highlights a broader issue for defenders: security controls around local AI gateways may still lag behind the level of access those tools now hold.
Why localhost Is Not a Security Boundary
The research underscores a long-standing but still misunderstood point: a service bound to localhost is not necessarily protected from browser-based attacks.
Developers often assume that anything listening only on the loopback interface is effectively isolated from the internet. But browsers can blur that boundary. A website cannot freely read arbitrary data across origins, yet it may still be able to initiate requests, including WebSocket connections, to services running locally.
“The modern web browser acts as a porous membrane, permitting untrusted, external JavaScript to bridge the gap to local services via WebSockets,” said Jason Soroko, senior fellow at Sectigo. “By relying on a local IP address to grant immunity from rate-limiting and to silently auto-approve device pairings, the system abandons the core tenets of a zero-trust architecture.”
That distinction is central to the ClawJacked chain. The attack did not require remote network access to the laptop. It used the victim’s own browser as the bridge between a website and a trusted local service.
For AI agents, that matters because compromising the local gateway can expose the systems and services the agent connects to. These tools are designed to act on behalf of users, connecting to APIs, workflows, and other applications. If the gateway is compromised, the attacker may gain access not just to one app, but to the layer coordinating multiple services.
The Bigger Lesson for Security Teams
ClawJacked is significant beyond one product because it shows how browser-accessible local services can become a new class of risk as agentic AI tools spread across developer and enterprise environments. More products now rely on local gateways that sit between browsers, models, and internal systems, but those services may not fit neatly into older assumptions about desktop software or cloud applications.
Security teams should assume that browser-based access to localhost is possible and design accordingly. That means applying authentication and rate limiting uniformly, including to loopback traffic, and requiring explicit trust decisions for actions such as pairing or administrative access.
“This research from Oasis Security’s research team is an important reminder that AI agents running on developer machines must be treated as highly privileged systems,” said Diana Kelley, chief information security officer at Noma Security. “The core issue was misplaced trust in local connections. ‘Local’ does not automatically mean ‘safe.’”
Kelley said organizations should review how their AI tools authenticate access, enforce rate limits, and require explicit user approval before granting control.
It also means inventorying agent gateways the same way teams would inventory other high-privilege control layers. If a local AI service can access credentials, source code, internal APIs, deployment pipelines, or logs, it should be monitored and hardened as if it were exposed infrastructure.
The core shift is that AI agents are becoming operational intermediaries. They are not just answering questions; they are connecting systems and performing tasks. As that role expands, so does their value to attackers.
