This is a valet key hidden in a URL that your browser hands to a stranger
OpenClaw before 2026.1.29 trusts a user-controlled gatewayUrl in the Control UI query string and auto-connects to it, sending the stored gateway token during the WebSocket handshake. Per the vendor advisory and NVD, affected versions are <= 2026.1.28, fixed in 2026.1.29. The practical result is token exfiltration and then operator-level control of the OpenClaw gateway API, which can be turned into command execution because OpenClaw is built to read files, run commands, and manipulate integrations.
The vendor's 8.8 HIGH is basically fair, but not because this is broad unauthenticated internet RCE in the classic sense. The real risk amplifier is that *localhost is not a defense here* once a logged-in user loads attacker content; the real friction is that the attacker still needs both user interaction and an authenticated OpenClaw UI session. That keeps it out of CRITICAL, but the post-click blast radius on a compromised operator workstation is bad enough to keep it firmly HIGH.
5 steps from start to impact.
Deliver a poisoned OpenClaw URL
gatewayUrl parameter. The published research from depthfirst shows the browser UI parses this parameter and auto-connects on load, so the victim does not need to manually re-enter a gateway address.- Victim uses OpenClaw Control UI
- Victim clicks a crafted link or visits attacker-controlled content
- Affected version is
<= 2026.1.28
- Requires user interaction (
UI:R), so this is not wormable from the network alone - Only matters for organizations actually deploying OpenClaw
Steal the gateway token over WebSocket
GHSA-g8p2-7wf7-98mq. This is the decisive bug: the product turns a URL parameter into an authenticated outbound connection.- Victim has previously authenticated to the Control UI and still has a stored token
- Browser can make outbound WebSocket connections
- No token to steal if the user never authenticated or has already logged out
- Strict egress controls or browser isolation can break the outbound WebSocket leg
ws:// or wss:// connections from a browser to nonstandard hosts, but signature coverage is likely weak.Re-use the stolen token against the real gateway
ws://localhost:18789 when origin checks are absent.- Gateway token remains valid
- OpenClaw gateway is reachable locally or remotely from the victim context
- Short token lifetime or forced re-auth reduces usefulness
- If the environment blocks browser access to local services or uses strong origin validation in newer builds, the chain breaks
Disable guardrails through the API
- Stolen token has operator/admin scopes
- Default approvals or sandbox settings are still modifiable through the API
- Read-only or heavily constrained deployments reduce impact
- Config drift monitoring can catch suspicious changes if anyone is watching
exec.approvals, config.patch, or execution-host settings. Most commodity scanners will miss this.Execute commands and loot connected services
- OpenClaw has meaningful local privileges or connected secrets
- Host controls do not block spawned commands or secret access
- Running OpenClaw as a low-privilege user limits host blast radius
- EDR or application control may stop child-process execution or suspicious file access
The supporting signals.
| In-the-wild status | No authoritative evidence found that CVE-2026-25253 itself is in active exploitation. CISA KEV does not list it as of the latest catalog check. |
|---|---|
| Proof-of-concept availability | Yes. The depthfirst research includes a working exploit chain narrative, and NVD tags the depthfirst and Ethiack references as Exploit references. Expect copycat tradecraft even without a turnkey Metasploit module. |
| EPSS | 0.00121 (~0.12%), from the upstream EPSS intel in your prompt. That's low and argues against panic patching solely on predicted mass exploitation. |
| KEV status | Not KEV-listed. No CISA due date pressure, and no public federal signal that exploitation crossed the threshold for catalog inclusion. |
| CVSS vector | CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H — the key friction is UI:R; the key impact amplifier is full C/I/A once the token is stolen. |
| Affected versions | GitHub Advisory and NVD both point to <= 2026.1.28 / before 2026.1.29. |
| Fixed version | Patched in 2026.1.29. GHSA says the change requires user confirmation before switching to a new gateway URL. |
| Exposure reality | This is not a tiny niche blast radius problem. Censys reported 21,639 exposed instances as of 2026-01-31, and Bitsight reported 30,000+ exposed instances during the same surge period. |
| Why localhost does not save you | GHSA explicitly states exploitation works even for loopback-only instances because the victim browser initiates the outbound connection. The depthfirst chain also shows a browser pivot to ws://localhost:18789 when origin validation is absent. |
| Disclosure | NVD published the CVE on 2026-02-01. GHSA was published 2026-01-31 and reviewed 2026-02-02. |
noisgate verdict.
The single most important downward pressure is that this attack *requires an authenticated OpenClaw UI user to interact with attacker content*; that is real friction, and it narrows the reachable victim population versus true unauthenticated internet RCE. It stays HIGH because once that condition is met, the attacker gets operator-grade control over a product that is explicitly designed to run commands and access sensitive local and connected resources.
Why this verdict
- Keeps vendor baseline mostly intact: token theft becomes gateway takeover, and gateway takeover in OpenClaw is practically code execution because the product is built for command execution and secret access.
- One-click but not zero-click: the attacker needs a victim to load malicious content *and* that victim needs an authenticated Control UI session. That is a meaningful real-world friction point, so I shave the score below the vendor's
8.8. - Local-only deployments are still exposed: GHSA and the depthfirst write-up both make clear that loopback binding does not neutralize this issue, because the browser becomes the network pivot.
- Population is narrower than mainstream enterprise software: OpenClaw is noisy and risky where deployed, but this is not Windows, Chrome, Exchange, or a top-edge device class. Product prevalence limits enterprise-wide systemic urgency.
- Exposure numbers are still ugly: Censys and Bitsight both found tens of thousands of exposed instances, which prevents a downgrade into
MEDIUMdespite the user-interaction requirement. - Threat intel is not screaming mass exploitation: no KEV listing and the supplied EPSS is very low, so there is not enough external pressure to push this into
CRITICAL.
Why not higher?
This is not unauthenticated drive-by network exploitation against every reachable instance. The chain requires a user click or visit, a live authenticated UI context, and a deployment that actually uses OpenClaw in the first place. Those are compounding prerequisites, and each one meaningfully reduces enterprise-wide exploitability.
Why not lower?
Once the prerequisites are satisfied, the impact is not theoretical or cosmetic. The stolen token grants meaningful operator control, and OpenClaw's own API can be abused to disable guardrails and run commands. Tens of thousands of exposed instances and the ability to compromise even loopback-only setups keep this above MEDIUM.
What to do — in priority order.
- Block unapproved OpenClaw versions — Use EDR, package management, or CI policy to deny execution or rollout of
<= 2026.1.28. For aHIGHverdict, deploy this compensating control within 30 days unless patching lands first. - Force re-authentication — Invalidate existing gateway/UI tokens where operationally feasible so any previously stolen token dies early. This reduces replay value while you work toward the vendor fix; for
HIGH, complete within 30 days. - Constrain browser-to-WebSocket egress — Apply proxy, firewall, browser isolation, or outbound filtering controls that make arbitrary browser-initiated WebSocket connections to unknown destinations harder. This directly attacks the token-exfil leg and should be in place within 30 days.
- Run OpenClaw as a low-privilege account — Drop local privileges, isolate working directories, and remove unnecessary access to cloud creds, SSH material, and admin-only resources. This does not fix the bug, but it cuts blast radius if exploitation occurs; do it within 30 days.
- Alert on dangerous gateway changes — Monitor for
config.patch, approval-policy changes, execution-host changes, and suspicious child-process launches from OpenClaw or browser-adjacent contexts. Instrumentation can be rolled out within 30 days and gives you a fighting chance to catch abuse.
- Binding OpenClaw to
127.0.0.1alone does not solve this; the published exploit chain specifically abuses the victim browser as the bridge. - Relying on default confirmation prompts is weak because the attacker can use the stolen token to change approval settings through the API.
- Internet perimeter blocking alone is incomplete if users run OpenClaw locally and browse untrusted content from the same workstation.
- Version-only network scanners may tell you an instance is old, but they do not validate whether token reuse, browser pivoting, or post-auth API abuse is currently possible.
Crowdsourced verification payload.
Run this on the target host that has OpenClaw installed, or via your software distribution/remote execution tooling. Invoke it as python3 verify_openclaw_cve_2026_25253.py or python verify_openclaw_cve_2026_25253.py; no admin rights are required unless your environment restricts access to the openclaw binary.
#!/usr/bin/env python3
# verify_openclaw_cve_2026_25253.py
# Checks whether installed OpenClaw version is vulnerable to CVE-2026-25253.
# Exit codes:
# 0 = PATCHED
# 1 = VULNERABLE
# 2 = UNKNOWN
import re
import shutil
import subprocess
import sys
PATCHED_VERSION = (2026, 1, 29)
def parse_version(text):
# Accept forms like:
# 2026.1.29
# v2026.1.29
# openclaw 2026.1.29
m = re.search(r'v?(\d{4})\.(\d+)\.(\d+)', text)
if not m:
return None
return tuple(int(x) for x in m.groups())
def get_version_output():
exe = shutil.which('openclaw') or shutil.which('clawdbot') or shutil.which('moltbot')
if not exe:
return None, 'binary not found in PATH'
commands = [
[exe, '--version'],
[exe, 'version'],
]
for cmd in commands:
try:
proc = subprocess.run(cmd, capture_output=True, text=True, timeout=10)
out = (proc.stdout or '') + '\n' + (proc.stderr or '')
if out.strip():
return out.strip(), None
except Exception as e:
last_error = str(e)
return None, last_error if 'last_error' in locals() else 'unable to execute version command'
def compare_versions(a, b):
return (a > b) - (a < b)
def main():
output, err = get_version_output()
if output is None:
print(f'UNKNOWN - could not determine version: {err}')
sys.exit(2)
version = parse_version(output)
if version is None:
print('UNKNOWN - version string not recognized')
print(output)
sys.exit(2)
if compare_versions(version, PATCHED_VERSION) >= 0:
print(f'PATCHED - detected version {version[0]}.{version[1]}.{version[2]} (fixed in 2026.1.29)')
sys.exit(0)
else:
print(f'VULNERABLE - detected version {version[0]}.{version[1]}.{version[2]} (< 2026.1.29)')
sys.exit(1)
if __name__ == '__main__':
main()
If you remember one thing.
2026.1.29 or later within 180 days; if you find exposed instances tied to sensitive integrations, do them first, not last.Sources
What defenders are saying.
Crowdsourced verification outputs.
Results submitted by users who ran the verification payload against their environment.