A dark-navy editorial illustration headed 'Any web page could reach the agent on your machine': an open browser window labelled 'a page you visited' on the left sends a thin amber line across a dark gap into a glowing gateway node labelled 'gateway 127.0.0.1', which fans out by three lines to three small device nodes labelled 'paired nodes'.
AI Safety Incidents

ClawJacked: any website could brute-force a local OpenClaw agent

Author

Alistair Wren

Date Published

Latest models · 20View all models →
Benchmarks: Artificial Analysis · updated daily
Back to all posts

ClawJacked, a vulnerability Oasis Security disclosed in the open-source AI agent OpenClaw on 26 February 2026, let any website a developer visited open a connection to the agent running on their own machine and guess its password until it handed over control. No click, no plugin and no prompt were needed. The prize was the gateway that orchestrates the agent: an intruder who got in could talk to the agent directly, dump its configuration, list every paired device and read its logs. Oasis, a vendor of agentic access management software, demonstrated the chain end to end in its own lab and reported it privately, and OpenClaw shipped a fix in under 24 hours. No source cited in this article records the attack being used against a real user. The archive files the episode as a high-severity infrastructure incident with a day-precision date of 25 February 2026 and no recorded real-world harm, alongside the rest of its OpenClaw entries in the Orca AI Incident Archive.

Three defaults, one chain

OpenClaw is a self-hosted personal agent that its users drive from a web dashboard or a terminal, and that connects to messaging apps, calendars and developer tools and acts inside them. At its centre is a gateway, a local WebSocket server that Oasis describes as "the brain of the operation": it handles authentication, stores configuration, manages chat sessions and dispatches commands to nodes such as a macOS companion app or an iPhone. Authentication is by token or by password, and the gateway binds to localhost by default, on the explicit assumption that local access is inherently trusted (Oasis Security, 26 February 2026).

Three consequences of that assumption chained together. First, browsers do not apply cross-origin rules to WebSocket connections the way they do to ordinary HTTP requests, so JavaScript on any page the user visits can open a socket to the local gateway port with nothing visible on screen. Second, the gateway's rate limiter exempted loopback connections entirely, so failed password attempts from 127.0.0.1 were not counted, throttled or logged. Third, the gateway auto-approved device pairings arriving from localhost, so an authenticated script could register itself as a trusted device without the confirmation prompt a remote device would trigger.

Oasis measured the guessing rate in its own lab and reported it in the disclosure: "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." BleepingComputer, which covered the disclosure on 1 March 2026, describes the same three steps and the same order.

A four-panel card titled 'Three defaults, chained', numbered 01 to 04: a page opens a WebSocket to the local gateway; the password is guessed at hundreds of attempts per second because loopback was exempt from the rate limiter; the script self-registers as a trusted device without a prompt; and the result is an authenticated operator session.

What an attacker gets, and what Oasis actually showed

Once authenticated, the script held an operator session with admin-level permissions. Oasis lists four things it can then do directly: send messages to the AI agent and read its replies, dump the gateway configuration, which reveals the AI providers, models and messaging channels in use, enumerate every connected node with its platform and IP address, and read the application logs. From there Oasis describes, rather than demonstrates, the escalation: instructing the agent to search the developer's Slack history for API keys, reading private messages, exfiltrating files from paired devices, or running arbitrary shell commands on any paired node. The firm's summary of the outcome is that for a developer with typical OpenClaw integrations this amounts to "full workstation compromise, initiated from a browser tab".

The demonstration Oasis published, with a video proof of concept, is narrower than that description: a browser on an unrelated site guessed the gateway password, connected with full permissions and successfully interacted with the user's agent, with no indication shown to the user. The file exfiltration and shell execution are described as what the access makes possible, not as steps the proof of concept carried out. That distinction matters when the record is read as a realised incident rather than a demonstrated one.

The patch landed in 2026.2.25, not in 2026.2.26

Oasis told readers to update to version 2026.2.25 or later, and OpenClaw's own advisory agrees with it. The GitHub advisory, GHSA-jmmg-jqc7-5qf4, lists affected versions as 2026.2.24 and below, patched versions as 2026.2.25 and above, and credits the report to @luz-oasis, the Oasis research lead Elad Luz. The npm registry timestamp for 2026.2.25 is 04:16 UTC on 26 February 2026, and the project's release notes for that version describe the fix in terms that map one-to-one onto the three defaults: "Security/Gateway WebSocket auth: enforce origin checks for direct browser WebSocket clients beyond Control UI/Webchat, apply password-auth failure throttling to browser-origin loopback attempts (including localhost), and block silent auto-pairing for non-Control-UI browser clients."

Two of the news reports name a different number. BleepingComputer says the fix was "released in version 2026.2.26 on February 26", and SecurityAffairs repeats that 2026.2.26 was the release that addressed the issue while its own advice paragraph tells readers to update to 2026.2.25 or later. Infosecurity Magazine, covering the disclosure on 2 March 2026, cites 2026.2.25. Release 2026.2.26 does exist, but npm records it at 23:59 UTC on 26 February, roughly twenty hours after 2026.2.25, and its notes are a separate batch of hardening. The fix a reader should look for is the one in 2026.2.25.

The identifier came later. The GitHub advisory was published on 3 March 2026 under CVE-2026-32025, and NVD's record for it was published on 19 March 2026 with a CVSS 3.1 base score of 7.5, rated high by NVD as the primary scorer and by VulnCheck as a secondary one. The advisory itself is more careful than the score: its own severity field reads moderate, and its text calls the bug "serious, but conditional", spelling out four preconditions — the gateway reachable on loopback, password authentication in use, the victim opening attacker-controlled web content, and a password guessable within feasible attempts. It also states plainly what the bug is not: "This is not an unauthenticated internet-exposed RCE class issue by itself; it is a local browser-origin auth-hardening gap with meaningful impact under the conditions above."

A vertical timeline card with seven dated rows: 28 to 31 January 2026 an independent scan counts 42,665 internet-exposed instances; 9 February SecurityScorecard counts 40,214 with 35.4% flagged vulnerable; 26 February 04:16 UTC npm release 2026.2.25 ships the fix; 26 February Oasis publishes; 1 to 2 March outlets report it; 3 March the GitHub advisory is published as CVE-2026-32025; 19 March NVD publishes at CVSS 7.5.

Where the 42,665 comes from, and why it is not a ClawJacked number

The archive's summary records that 42,665 instances were exposed at disclosure, and notes that SecurityScorecard gives a different figure of 40,214, of which 35.4% were vulnerable. None of the three sources cited for this record contains either number — Oasis, BleepingComputer and SecurityAffairs all describe the vulnerability without attaching an installed-base count. Both figures come from somewhere else, and both were published before ClawJacked existed.

The 42,665 is an independent scan. Maor Dayan, a security researcher who published his findings on Medium, built a scanner called ClawdHunter v3.0 and ran it over Shodan and Censys data collected between 28 and 31 January 2026, reporting "at least 42,665 instances" of OpenClaw publicly exposed on the internet, of which 5,194 were actively verified as vulnerable and 93.4% of those verified showed an authentication bypass. The 40,214 is SecurityScorecard's STRIKE team, in research published on 9 February 2026, which counted internet-exposed OpenClaw instances and flagged 15.2K as vulnerable to remote code execution, with "35.4% of observed deployments flagged as vulnerable". SecurityScorecard's own summary bullets give 42.9K unique IP addresses hosting exposed control panels, alongside the 40,214 confirmed instances in its body text — two different measurements inside one report.

Neither number measures ClawJacked's reach, because both count instances answering on a public interface. ClawJacked's precondition is the opposite configuration: a gateway bound to loopback, in password mode, on a machine whose user browses to a hostile page. A server counted in an internet-wide scan may sit behind its own auth and be untouched by this bug, while the laptop that never appears in such a scan is exactly the target Oasis described. The archive's own phrasing, "at disclosure", therefore attaches a January population count to a February vulnerability. The counts are real measurements of how much OpenClaw was exposed; they are not a count of the machines ClawJacked could have taken over. This article is not adjudicating a dispute — the record is not marked disputed — but the provenance of the two figures is checkable and does not support the "at disclosure" framing.

A two-column comparison card headed 'Exposed is not the same as hijackable'. The left column, 'What the exposure scans counted', lists 42,665 internet-reachable instances from a January 2026 scan and 40,214 from SecurityScorecard's February 2026 census with 35.4% flagged vulnerable. The right column, 'What ClawJacked required', lists a loopback-bound gateway in password mode, a user visiting attacker-controlled content and a guessable password.

What is established, and what is not

Established: that Oasis Security found the chain and demonstrated it in a lab; that OpenClaw's own advisory and release notes confirm all three behaviours — missing origin enforcement for browser WebSocket clients, absent throttling for loopback password attempts, silent auto-pairing — and that 2026.2.25 changed each of them; that the fix shipped within a day of the report; and that three outlets outside the finder's own blog covered it. The archive's confidence grade of A is consistent with that record, and nothing here is disputed by the parties involved.

Not established: that anyone used it. No source cited here, and none found in the coverage around the disclosure, reports a real-world compromise, a victim, or data taken. Oasis's is a lab demonstration and the write-up describes attacker capability rather than observed attack. That is consistent with the archive recording no real harm, and it is the single most important qualifier on the story: this is a vulnerability record, not a breach report.

Two labels in circulation are wrong, and both are easy to inherit. Several secondary write-ups attach CVE-2026-25253 to ClawJacked. NVD's record for that identifier describes a different bug in the same product: OpenClaw before 2026.1.29 taking a gatewayUrl from a query string and connecting to it without prompting while sending a token, a one-click token theft with a CVSS score of 8.8, published on 1 February 2026 and fixed on 29 January. That is the January vulnerability, with a different mechanism and a different patch. ClawJacked's identifier is CVE-2026-32025. Infosecurity Magazine, meanwhile, described ClawJacked as an indirect prompt injection; the chain Oasis documented involves no prompt and no model decision at all — it is an authentication bypass that ends in an operator session.

What changed afterwards

OpenClaw patched it, published the advisory and credited the reporter, and the CVE was assigned within a week of the public write-up. Oasis's recommendations to organisations go beyond the patch: inventory which agents and assistants are running across developer machines, update every instance, audit what credentials and capabilities each one holds and revoke what is not in use, and govern agents as non-human identities with intent checks, policy enforcement, just-in-time access and an audit trail from human to agent to action. The firm sells software in that last category, which is worth knowing when weighing the last recommendation against the first three.

The wider context is that ClawJacked was one advisory in a flood. The GitHub advisory database carries a large batch of OpenClaw advisories dated 3 March 2026 — the same day ClawJacked's was published — covering separate authentication, pairing, path-traversal and sandbox-escape bugs across versions 2026.2.19 to 2026.2.26. The pattern the ClawJacked record preserves is narrower than "AI agents are insecure" and more useful: the gateway treated loopback as a trust boundary, and the browser made that assumption false. Any local service that exempts 127.0.0.1 from throttling, and any device-pairing flow that auto-approves local callers, inherits the same shape whether or not an AI model is behind it. In this instance the model was never the vulnerable component — the authentication layer around it was.