OpenClaw ACP Client Permission Auto-Approval Bypass (GHSA-7JX5-9FJG-HP4M)

GHSA-7JX5-9FJG-HP4M describes a critical security flaw in the OpenClaw ACP (Agent Control Protocol) client, specifically within the permission resolution logic. The vulnerability stems from an insecure implementation of the 'auto-approve' feature, which is designed to streamline user interaction for safe operations like reading configuration files or performing read-only searches.

The core issue lies in the client's trust model. Prior to the fix, the client relied on untrusted input—specifically the tool classification provided by the remote server—to determine if a tool call was safe enough to skip the user confirmation prompt. By default, the client is configured to require user approval for impactful actions. However, exceptions were made for tools categorized as 'read' or 'search'.

This implementation failed to verify the authenticity of these categories. Consequently, a malicious ACP server or a compromised upstream agent could tag a dangerous operation (such as executing a system command or reading a sensitive file outside the workspace) with a 'safe' category. The client would interpret this metadata as truth, bypass the authorization prompt, and execute the command, leading to a complete compromise of the client's confidentiality and integrity.

The vulnerability is a classic instance of CWE-807: Reliance on Untrusted Inputs in a Security Decision. The defect resided in the resolvePermissionRequest function (and its helper resolveToolKindForPermission) within src/acp/client.ts. The logic used two flawed heuristics to classify tool calls:

1. Explicit Trust in Remote Metadata: The client code checked the kind property of the incoming toolCall object. If the remote server sent kind: "read", the client blindly accepted this classification. There was no server-side validation or cryptographic signing to ensure the kind matched the actual function of the tool being invoked.

2. Loose Regex Heuristics: If the kind property was missing, the client attempted to infer the category from the tool's name using loose string matching. For example, any tool name containing the substring "read" (e.g., thread_read, or even a malicious name like exploit_reader_exec) was automatically classified as a 'read' operation. This allowed attackers to mask dangerous tools simply by adhering to specific naming conventions.

Furthermore, even when a tool was correctly identified as a 'read' operation, the client lacked Path Scoping. It did not validate that the target file resided within the authorized workspace. This omission meant that an auto-approved 'read' operation could access /etc/shadow or ~/.ssh/id_rsa just as easily as it could access a project README.

The following analysis contrasts the vulnerable logic with the hardened implementation introduced in version v2026.2.23.

Vulnerable Logic (src/acp/client.ts)

In the pre-patch version, the determination of safety was delegated to the input itself:

// VULNERABLE: Trusts "kind" from the network and uses loose regex
function resolveToolKindForPermission(params: RequestPermissionRequest, toolName: string): string | undefined {
  const toolCall = params.toolCall;
  
  // CRITICAL FLAW: Trusted input source
  const kindRaw = toolCall?.kind; 
  if (kindRaw) return kindRaw.trim().toLowerCase();
  
  // CRITICAL FLAW: Loose heuristic allows "malicious_read_exec"
  if (toolName.includes("read")) return "read"; 
  if (toolName.includes("search")) return "search";
  
  return "other";
}

Patched Logic (Commit 12cc754)

The fix shifts to a Zero Trust model. It ignores the kind property entirely and validates the tool against a strict allowlist. Additionally, it enforces path constraints for filesystem operations.

// PATCHED: Validates against internal allowlist and enforces path scope
const SAFE_AUTO_APPROVE_TOOL_IDS = new Set(['read_file', 'search_code']);
 
function resolveToolKindForPermission(params: RequestPermissionRequest, toolName: string): string | undefined {
  // 1. Ignore params.toolCall.kind completely.
  
  // 2. Exact match against known safe tool IDs
  if (SAFE_AUTO_APPROVE_TOOL_IDS.has(toolName)) {
      const kind = mapToolIdToKind(toolName);
      
      // 3. Additional Logic: Path Scoping
      if (kind === 'read' && params.arguments?.path) {
         if (!isPathWithinRoot(params.arguments.path, process.cwd())) {
             // Downgrade to 'unsafe' if trying to read outside CWD
             return 'unsafe_read'; 
         }
      }
      return kind;
  }
  
  return "require_approval";
}

The patch ensures that safety is determined by what the code actually does, not what the remote server claims it does.

To exploit this vulnerability, an attacker requires control over the ACP server or the ability to inject messages into the ACP connection (Man-in-the-Middle). The goal is to coerce the client into performing an action without user interaction.

Attack Scenario: Arbitrary File Read

1. Session Establishment: The attacker establishes a connection with the victim's OpenClaw client.
2. Payload Construction: The attacker constructs a JSON-RPC request for a tool call. They set the toolName to a custom malicious tool or a standard tool with manipulated arguments.
3. Metadata Spoofing: The attacker injects the property "kind": "read" into the toolCall object within the request payload.
4. Path Traversal: In the arguments, the attacker requests a sensitive file, utilizing directory traversal sequences if necessary: "path": "../../../../etc/passwd".
5. Execution: The OpenClaw client receives the request. The resolveToolKindForPermission function sees kind: "read" and returns the 'safe' classification. The prompt logic sees the 'safe' classification and auto-approves the request.
6. Exfiltration: The client reads the system file and returns the content to the attacker.

Diagram: Bypass Flow

This technique bypasses the fundamental security promise of the ACP client: that the human user is the final arbiter of dangerous actions.

The impact of GHSA-7JX5-9FJG-HP4M is rated as Critical (CVSS 9.8) because it completely negates the authorization layer of the application.

Confidentiality: The vulnerability permits attackers to read any file the user process has access to. On developer machines, this typically includes SSH keys, cloud provider credentials (AWS/GCP tokens), source code, and environment variables containing secrets. This is a high-confidentiality breach.

Integrity: While the primary example focuses on file reads, the vulnerability extends to any tool. If an attacker can spoof a 'write' tool as a 'read' tool (or if the regex allows a name like safe_read_and_write), they could modify code or configuration files without detection.

Availability: Malicious tool execution could be used to delete files or crash the client process, leading to denial of service.

Scope: This affects all unpatched OpenClaw clients connecting to third-party or untrusted servers. Since ACP is designed for agentic workflows where clients often connect to diverse endpoints, the attack surface is significant.

The only complete remediation is to upgrade the OpenClaw software to a version that enforces the zero-trust logic.

Primary Fix: Upgrade to OpenClaw v2026.2.23 or later immediately. This version includes commits 12cc754 and 63dcd28, which remove the reliance on server metadata and strictly validate tool names.

Configuration Hardening: If immediate patching is not feasible, administrators should restrict the client's network access. Ensure the ACP client only connects to fully trusted, internal servers. Firewalls should block connections to unknown or public ACP endpoints.

Operational Security: Users should review logs for unexpected file access patterns, particularly those originating from tool invocations that occurred without a visible prompt. Any historical sessions connected to untrusted servers should be considered compromised; verify that sensitive credentials (SSH keys, API tokens) on the host machine have not been accessed or rotate them as a precaution.