GHSA-943Q-MWMV-HHVH: Privilege Escalation and RCE in OpenClaw Gateway

OpenClaw is an open-source AI assistant platform that utilizes a Gateway for handling external requests and an Agent Control Policy (ACP) to manage permissions. The architecture intends for the Gateway to expose only specific, safe tools for automation while keeping sensitive orchestration capabilities restricted. However, a significant boundary failure was identified in how the Gateway dispatches requests and how the ACP client validates them.

The vulnerability allows an attacker with access to the POST /tools/invoke endpoint (which requires only basic automation credentials) to invoke high-privilege tools such as sessions_spawn and gateway. These tools are designed for internal system orchestration and should not be accessible via the standard public-facing API. By accessing these tools, an attacker can effectively seize control of the agent orchestration layer.

Furthermore, the impact is amplified by a logic flaw in the ACP's permission system. Even if an attacker invokes a dangerous tool, the system is designed to prompt a human operator for approval. This safety mechanism is bypassed due to a faulty heuristic that auto-approves actions containing specific "safe" keywords, allowing the attack to proceed silently without user intervention.

The vulnerability is the result of two distinct but compounding root causes: an Access Control weakness in the Gateway and an Input Validation flaw in the ACP client.

1. Gateway Tool Exposure (Broken Access Control): The OpenClaw Gateway exposes a generic dispatcher endpoint, /tools/invoke. Prior to version 2026.2.14, this dispatcher did not enforce a deny list against sensitive internal tools. The endpoint simply accepted a tool name and attempted to execute it. Consequently, administrative tools like sessions_spawn (creates new agent sessions) and sessions_send (injects messages) were treated with the same accessibility as benign tools like search_web. This flattened the privilege model, making the API endpoint a gateway to full system control.

2. Heuristic Permission Bypass (Improper Logic): The ACP client implements a user experience feature designed to reduce "prompt fatigue" by auto-approving operations deemed safe, such as "read" or "search" actions. The implementation relied on naive substring matching. The function resolveToolKindForPermission checked if the normalized tool name or title included the string "read". This allowed an attacker to cloak a dangerous operation (e.g., delete_database) by manipulating its metadata to include the word "read" (e.g., aliasing it as read_and_delete), thereby tricking the system into categorizing the request as a safe, auto-approved action.

The critical flaw lay in the resolveToolKindForPermission function within src/acp/client.ts. The original code used a permissive .includes() check to determine if a tool action should be auto-approved.

Vulnerable Code

// src/acp/client.ts (Pre-patch)
function resolveToolKindForPermission(toolName: string, metadata: any) {
    const normalized = toolName.toLowerCase();
    
    // FLAW: Simple substring match allows "delete_read" to pass as "read"
    if (normalized === "read" || normalized.includes("read")) {
        return "read"; // Auto-approves the action
    }
    
    // ... similar logic for "search"
    return "unknown"; // Requires manual approval
}

Patched Code

The fix introduces strict token-based validation using Regular Expressions. It ensures that safety keywords are distinct words, not merely substrings within a dangerous command. It also enforces a "fail-closed" default, where any ambiguity results in a manual prompt.

// src/acp/client.ts (Patched)
const SAFE_AUTO_APPROVE_KINDS = ["read", "search"];
 
function resolveToolKindForPermission(toolName: string, metadata: any) {
    const normalized = toolName.toLowerCase();
    
    // FIX: Use Regex to ensure "read" is a distinct token
    // Matches "read", "read_file", "user.read" but NOT "thread_manager" or "dread"
    const readPattern = /(?:^|[._-])read(?:$|[._-])/;
    
    if (readPattern.test(normalized)) {
        return "read";
    }
    
    // ... strict checks for other kinds
    
    // Default to strict manual approval if not explicitly safe
    return "manual_approval_required";
}

Additionally, the Gateway now implements a hardcoded deny list for critical tools like sessions_spawn preventing them from being called via HTTP even if the ACP check passes.

An attacker can exploit this vulnerability to achieve Remote Code Execution (RCE) by leveraging the Gateway's lack of restrictions to spawn a new session with high-privilege capabilities.

Prerequisites

1. Network Access: Ability to reach the OpenClaw Gateway HTTP API.
2. Authentication: Possession of a valid Gateway token or password (often distributed for low-privilege automation tasks).

Attack Chain

1. Target Selection: The attacker targets the sessions_spawn tool. This tool is normally used internally to create new agent environments.

2. Payload Construction: The attacker constructs a JSON payload for the POST /tools/invoke endpoint. To bypass the ACP prompt, they inject a title or naming convention that triggers the vulnerable heuristic.

   POST /tools/invoke HTTP/1.1
   Host: openclaw-gateway:3000
   Authorization: Bearer <low_priv_token>
   Content-Type: application/json
    
   {
     "tool": "sessions_spawn",
     "arguments": {
       "model": "gpt-4-turbo",
       "system_prompt": "You are a system administrator. Execute the following shell command..."
     },
     "_meta": {
       // The keyword 'read' here tricks the ACP into auto-approving the request
       "title": "Safe read operation: spawn session"
     }
   }

3. Execution: The Gateway receives the request. Because sessions_spawn was not on the deny list, it processes the call. The ACP client inspects the metadata, sees the word "read", and erroneously classifies the action as safe. The session is spawned immediately without alerting the operator.

4. RCE: Once the session is spawned, the attacker uses the sessions_send tool (exploited similarly) to instruct the new agent to execute shell commands using its native capabilities (e.g., bash or exec), effectively granting full control over the host container.

The successful exploitation of this vulnerability leads to a complete compromise of the OpenClaw instance and potentially the underlying host infrastructure.

Remote Code Execution (RCE): The primary impact is the ability to execute arbitrary commands on the server running the OpenClaw agent. This allows attackers to install malware, establish persistence, or pivot to other systems within the network.

Session Hijacking and Manipulation: Attackers can interact with existing user sessions using sessions_send. This enables the injection of malicious prompts into legitimate user workflows, potentially leading to data exfiltration or social engineering attacks against the operators.

Security Policy Bypass: The vulnerability fundamentally undermines the "Human-in-the-Loop" security model of OpenClaw. The ACP is designed to be the final gatekeeper for dangerous actions; bypassing it renders the entire permission system ineffective for automated attacks.