CVSS: 9.9

Target Service

OpenClaw

  • A system that handles command execution, tool invocation, and remote operations through WebSocket-based communication between gateways and nodes.
  • Provides the ability to execute commands such as system.run for connected node hosts
  • Receives authenticated client requests at the gateway and forwards them to target nodes through the node registry.
  • Includes an approval-based security gate that controls whether dangerous commands may execute.

Affected Versions

  • Affected versions: OpenClaw versions earlier than 2026.2.14
  • Patched version: OpenClaw 2026.2.14 or later

Vulnerability Overview

Vulnerability Types

  • RCE
  • Remote code execution after authentication
  • Approval bypass
    • When node.invoke is called, internal approval fields are not sanitized, allowing the execution-approval gate to be bypassed.
  • Parameter injection
    • An attacker can insert approval-control fields into the params object of node.invoke.
  • Trust-boundary violation
    • The gateway trusts client-supplied approval fields and forwards them unchanged to the node.

Root Cause

  • There was a design flaw in the node.invoke delivery logic of the OpenClaw gateway.
  • When an authenticated client sends a node.invoke request through WebSocket, the gateway maps it to a handler and then performs AJV verification.
  • However, in the verification, params is defined as Type.Unknown(), so the internal structure is not verified.
  • As a result, even if an attacker includes internal approval fields such as approved and approvalDecision in params, the request is passed as a valid request.
  • The node.invoke handler checks whether the command is permitted, but does not separately filter or remove fields within p.params.
  • The attacker-supplied approval-control fields therefore reach the node registry unchanged and are sent to the target node after JSON serialization.
  • The node side parses the received JSON again and checks for approval. If approved === true or the approvalDecision value exists, the structure allows command execution.
  • In particular, if approvalDecision === “allow-always”, the action of being added to the permanent allow list was even possible.
  • Fields that should only be set by the gateway’s internal approval process could instead be injected directly by the client. Because the gateway forwarded them across the trust boundary without sanitization, the flaw resulted in approval-bypass RCE.

Exploitation Mechanism

Attack Flow

  • Attacker → WebSocket connection as a client authenticated to the gateway
    • Send request node.invoke
    • Insert approval-control fields into params
  • Server-side processing
    • Accept WebSocket connection
    • Create connection ID
    • attachGatewayWsMessageHandler handles subsequent messages
  • Handler Mapping
    • String node.invoke is mapped to handlers in GatewayRequestHandlers via extraHandlers
  • Request Validation
    • The AJV validator checks the request, but does not inspect the internal structure because params is defined as Type.Unknown().
    • Approval fields inserted by the attacker pass through unchanged.
  • Running node.invoke handler
    • Check for presence of required fields
    • Perform command permission check
    • However, it does not remove or block approval fields within p.params.
  • forward to node
    • The node registry serializes the request to JSON and sends it to the target node.
  • Node-side execution
    • Node parses JSON and restores params
    • Treat the request as approved based on whether approved === true or approvalDecision exists.
    • Execute command system.run
  • result
    • Allows execution of arbitrary commands on connected node hosts
    • Response is returned to attacker

Once an attacker has authenticated gateway client credentials, they can construct and send a node.invoke request directly. If they include fields such as approved: true and approvalDecision: "allow-always" inside the request body’s params object—fields that should only be set by the internal approval process—the gateway accepts them without removing them.

Because the gateway’s AJV validation does not structurally inspect params, the attacker-supplied approval fields pass as part of a valid request. The node.invoke handler checks only whether the command itself is allowed and leaves the approval-control fields within the internal parameters untouched.

As a result, the approval field is delivered to the target node in the form of JSON through the node registry, and the node trusts it and processes it as an approved execution request. Ultimately, an attacker can execute the system.run command without going through the normal approval process, making it possible to execute arbitrary commands on node hosts such as connected developer workstations or configuration executors.

Patch Details

OpenClaw 2026.2.14

The gateway was changed to sanitize parameters before forwarding node.invoke requests.

  • Add sanitizeNodeInvokeParamsForForwarding function
    • Changed to leave only whitelist fields allowed in the params passed to the node.
  • Internal approval field direct injection blocking
    • Modified so that even if the client arbitrarily enters approval control fields such as approved and approvalDecision, they are not delivered.
  • Enhanced Approval ID Binding
    • Binds each approval ID to the requesting device, preventing reuse or replay from another device
  • Restrictions on enforcement of approval decisions
    • Demotes approval decisions to allow-once level to prevent injection of arbitrary persistent allow settings

After the patch, the gateway no longer trusts client input unchanged. It sanitizes internal approval-related fields before forwarding parameters to the node, blocking the approval-bypass RCE.

References

  • GHSA: GHSA-gv46-4xfq-jv58
  • Related commit: 0af76f5f0e93540efbdf054895216c398692afcd