One Click, Full Control
*Author:** Or Ben Ari **Focus:** Cyber Security & Malware Analysis | SOC / Blue Team **Date:** February 2026 ## Audience
Security Engineering • SOC • Product • Incident Response • Leadership stakeholders who need a clear, defensible risk narrative
## What this document is
A high-clarity internal write-up that explains:
- **What CVE-2026–25253 actually is** (beyond "a UI bug") - **Why the published CVSS 8.8 is defensible** - **How the exploitation chain works at a conceptual level** (no PoC, no step-by-step) - **What to monitor, how to respond, and how to harden** - **The broader lesson**: how seemingly small trust decisions in a control plane can collapse into "one click → credential loss → privileged control"
— -
## The story in one sentence
**OpenClaw's Control UI allows an attacker-supplied `gatewayUrl` to drive an automatic WebSocket connection that sends a stored token-creating a one-click token exfiltration path and downstream control-plane compromise.**
That is the incident. Everything else is the blast radius.
— -
# 1) Why this matters (without the hype)
This vulnerability is high-risk because it collapses multiple safeguards at once:
- It shifts a **security-critical routing decision** (which gateway to trust) into an attacker-controlled input (`gatewayUrl` in a query string). - It removes user intent by **auto-connecting on load**. - It transfers a **high-value secret** (token) during connection setup, enabling **privileged gateway actions** after exfiltration.
In operational terms, it turns a routine user action — opening a link — into a credible path for credential theft and control-plane abuse.
— -
## 2) Executive summary (strict, readable, accurate)
**CVE-2026–25253** affects **OpenClaw** (also referenced as **Clawdbot/Moltbot**) in versions **before 2026.1.29**. The issue is straightforward: the Control UI reads a **user-supplied `gatewayUrl` from the query string** and **auto-connects via WebSocket without prompting**, sending a **stored token** as part of the connection flow.
### Core failure
A **user-controlled URL parameter** becomes a **privileged endpoint selector**, and the UI **automatically initiates the connection** while **transmitting a stored authentication token**.
### Practical outcome (defensible impact)
If an attacker captures the token, they can **impersonate the operator to the gateway control plane** and perform **any actions permitted by that token**. The most universally defensible statement is:
> **Token exfiltration enables unauthorized privileged gateway operations.**
In many deployments, that access can be escalated into materially severe outcomes (including execution via privileged workflows), but downstream host impact remains **environment-dependent** (gateway capabilities, configuration, and available privileged actions).
### Fix boundary
Version **2026.1.29** is the **patched** release. The remediation aligns with the root cause: **stop silent trust of URL-driven endpoint changes** and require **explicit user confirmation** before applying a new gateway URL, preventing automatic token leakage to attacker-controlled endpoints.
— -
# 3) The real lesson: this is a control-plane integrity failure
The Control UI is not a passive interface; it is a **control-plane client**. When a UI can connect, authenticate, and invoke privileged actions, it becomes a security boundary itself.
CVE-2026–25253 is a textbook case of control-plane discipline being violated by convenience:
- "Let users override the gateway endpoint via URL for flexibility." - "Auto-connect to reduce friction." - "Attach the token so it just works."
Individually, these choices can sound harmless. In combination, they form a reliable pattern: **untrusted input → privileged routing → automatic secret transfer.**
That pattern is the vulnerability class. The specific implementation details (query string, WebSocket) are merely the transport.
— -
# 4) Root cause analysis (clean and defensible)
## 4.1 Primary flaw: untrusted input selects a privileged endpoint
`gatewayUrl` is attacker-controlled when supplied via query string. The UI treats it as authoritative enough to determine where it will establish a control-plane session.
This is the trust-boundary violation: **Untrusted input → security-critical endpoint selection.**
## 4.2 Secondary flaw: auto-connect transmits secrets without explicit intent
The UI connects _automatically_ and transmits a stored token as part of that connection flow. The absence of a prompt/confirmation at the moment the endpoint changes is a critical contributor.
## 4.3 Why "loopback-only" gateways do not eliminate risk
Even if a gateway binds to **loopback (127.0.0.1)**, the browser is still a fully capable network client: it can initiate **outbound** connections to remote infrastructure. This vulnerability is therefore not fundamentally about _reaching the legitimate gateway from the internet_ — it is about **where the client is tricked into sending its secret**.
### The real boundary: token egress from the client
The critical security failure is **token egress from the client**. Once a user-controlled `gatewayUrl` is accepted and an automatic WebSocket connection is initiated, the stored token can be transmitted to an attacker-controlled endpoint. At that point, loopback-only binding does not help: the secret has already left the client context, and the attacker can reuse it wherever that token is valid.
### Practical takeaway
Loopback-only reduces **inbound exposure** of the gateway service, but it does **not** remove the risk of **credential leakage** caused by client-side automatic connection behavior. In other words:
> **Loopback protects the gateway's listener — not the user's token.**
— -
# 5) Exploitation model (high-level, no PoC)
## Preconditions
- OpenClaw version **≤ 2026.1.28** (fixed in 2026.1.29) - User is already authenticated to Control UI (token exists in client storage/session context) - User opens a crafted URL (UI:R)
## Conceptual chain
1. Attacker supplies a URL with `gatewayUrl` pointing to attacker-controlled infrastructure. 2. Victim opens the URL. 3. Control UI auto-connects via WebSocket to the supplied endpoint. 4. Token is sent during connection setup. 5. Attacker captures token. 6. Attacker uses token to call gateway control-plane functionality, performing unauthorized privileged operations.
**Important precision:** "One click" is best described as **one click to token compromise**, which then enables privileged actions that may lead to full compromise depending on gateway permissions and execution pathways.
— -
# 6) CVSS 8.8 rationale (and the Scope discussion)
Published vector: **CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H = 8.8 (High)**
### Why each metric is defensible
- **AV:N**: delivered remotely via a link; the browser initiates a network connection. - **AC:L**: minimal conditions beyond token presence and user navigation. - **PR:N**: attacker needs no prior authenticated access on the victim system. - **UI:R**: user must open the URL. - **C/I/A:H**: a stolen control-plane token typically enables high-impact operations (confidentiality breach via access; integrity/availability impact via privileged actions).
### Scope (S:U vs internal discussion)
Public scoring uses **S:U**. Some internal models may argue that browser/UI and gateway/host are distinct trust domains and treat downstream compromise as **scope change**. That can be useful for internal risk narratives, but it should be presented explicitly as an internal modeling choice, not as a claim about the published CVSS.
— -
# 7) What SOC should prioritize (high signal) SOC here should optimize for **high-signal indicators** that map directly to the exploitation path: **unexpected client WebSocket destinations → token reuse anomalies → privileged control-plane bursts**.
## 7.1 Client-side telemetry (Web/Proxy)
Focus on **where the browser connects**, not only what the gateway exposes.
- **Unexpected WebSocket destinations** from devices/users that normally connect only to the legitimate gateway, now connecting to **new or first-seen hosts**. - **First-seen domains/hosts** contacted **immediately after** a user opens the Control UI (tight temporal coupling is high signal). - **Destination patterns consistent with gateway connectivity** (e.g., protocol/port behavior resembling the normal gateway session) but pointing to a host outside known allowlists.
**What to log / where**
- **Browser security telemetry / EDR (if available):** outbound connection events tied to the browser process. - **Proxy / SWG / Firewall logs:** WebSocket destinations, SNI/Host, timestamps, user identity mapping. - **DNS logs:** first-seen lookups that occur right before the WebSocket session.
## 7.2 Gateway-side behavioral detections (Control-plane)
Once a token is stolen, the gateway will often show **behavioral discontinuities**:
- **Token usage from unusual network locations** or new client fingerprints (new ASN/geo/device traits) relative to the operator's baseline. - **Compressed action sequences**: "config/policy change → privileged action invocation" within unusually short time windows. - **Burst patterns**: repeated administrative methods executed in automation-like cadence immediately after initial token use.
**What to log / where**
- **Auth logs:** token validation events, source IP/geo/UA/fingerprint (where available). - **API audit logs:** privileged methods invoked, object changes, and timestamps.
## 7.3 Token hygiene indicators (reuse & anomaly)
These are environment-agnostic and often the most defensible signals:
- **Same token reused** from multiple IPs/locations within a short window. - **Access outside normal time-of-day** for the operator (especially if paired with privileged actions). - **Atypical request mix**: administrative operations dominate vs. normal read/monitor usage.
**SOC triage rule of thumb** If you see **(unexpected WS destination)** _plus_ **(token reuse anomaly)**, treat it as **probable token exfiltration** and escalate quickly.
— -
# 8) Incident response posture (actions that actually reduce risk)
## Immediate actions
1. **Upgrade to 2026.1.29+**. 2. **Revoke/rotate gateway tokens** for users who authenticated on vulnerable versions (assume token exposure is plausible). 3. **Audit gateway configuration and policy history** for unauthorized or unexplained changes. 4. If compromise is suspected: preserve relevant logs, isolate affected hosts, and validate persistence/lateral movement.
``` [Exposure suspected/confirmed] | v [Containment] — Invalidate/rotate tokens & sessions — Block untrusted gatewayUrl / disable auto-connect — Allowlist known endpoints (temporary) | v [Evidence Preservation] — Browser/Proxy: WS destinations + timestamps — Gateway auth: token reuse anomalies — API audit: privileged ops burst / config changes | v {Signs of misuse?} — — No — → [Recovery + Monitoring] -> [Post-incident review] | Yes v [Eradication] — Revoke compromised creds / remove malicious configs — Apply fixes: endpoint validation + explicit confirmation + token lifecycle hardening | v [Recovery + Monitoring] -> [Post-incident review] ``` ### Why token rotation is mandatory (not optional)
The patch prevents future auto-exfiltration via this path. It does not invalidate tokens that may already have been exposed. Rotation is the only step that removes attacker-held credentials.
— -
# 9) Engineering hardening: preventing the class, not only the instance
The goal is to prevent **this entire class of failure**: _untrusted endpoint selection + automatic connection + secret attachment_. Fixing a single URL parsing bug is not enough — control-plane UX must treat endpoint choice as a **security boundary**. ## 9.1 Endpoint trust must be explicit and verifiable
Endpoint selection must be treated like an authentication boundary — not a convenience feature.
- **No silent endpoint switching** for any control-plane destination (UI must never "just follow" user-controlled routing). - **Allowlist / pinning** for gateway origins (only known gateway origins should be eligible). - **Clear, human-verifiable endpoint identity** (display the exact origin/identity the UI will connect to). - **Explicit confirmation** when introducing or changing endpoints (with a "why you're seeing this" explanation).
*Caption**: Endpoint selection treated as a security boundary: allowlist + identity display + explicit confirmation. ## 9.2 Never auto-transmit secrets on initial contact
A control UI should never send secrets to an endpoint before the user has explicitly confirmed **who** it is talking to.
- Establish **unauthenticated connectivity first** (handshake/health check), then require explicit user intent to authenticate. - **Bind authentication to validated origin/identity**, not to user-controlled routing. - Prefer **origin-bound tokens** (or equivalent binding) so secrets are not usable outside the intended gateway identity.
**Caption :** Two-phase model: connectivity first, authentication only after endpoint identity is confirmed. ## 9.3 Token model improvements (make stolen tokens less valuable)
If a token can be replayed broadly, exfiltration becomes a control-plane compromise. Reduce the blast radius:
- **Short-lived tokens** with rotation (reduce replay window). - **Audience/origin binding** so tokens are useless if presented to an unexpected gateway. - **Least-privilege scopes** for operator actions (avoid "one token = everything"). - **Server-side revocation** and anomaly-triggered invalidation (multi-IP / impossible travel / burst admin actions).
> Practical rule: assume tokens will leak; design so leakage is **non-catastrophic**.
## 9.4 Treat WebSockets as first-class control-plane APIs
WebSocket control paths must have the same security posture as HTTP APIs:
- Strong **authentication & authorization** - **Audit logging** for privileged operations - **Rate limiting** and abuse controls - **Method-level access control** (especially for configuration and execution paths)
>**If the UI can be convinced to connect, it can be convinced to leak.**
— - # 10) Key takeaway (professional, quotable)
**If untrusted input can select a control-plane endpoint, and the client automatically carries credentials to that endpoint, you have built a credential exfiltration channel into your product.**
CVE-2026–25253 is a reminder that "convenience" in control-plane UX is not neutral. It must be designed as a security boundary.
— -
## Note on your "follow-on CVE candidate"
One important correction for seriousness/accuracy: the Gateway WebSocket `config.apply` / `cliPath` command injection issue referenced by **GHSA-g55j-c2v4-pjcg** already appears to have a CVE assignment: **CVE-2026–25593** on cve.org. So in a formal doc, I would present it as an **adjacent, separately tracked vulnerability (already assigned)** rather than a "new candidate."
## Best regards,
**Or Ben Ari** Cyber Security & Malware Analysis | SOC / Blue Team