GHSA-V6X2-2QVM-6GV8: Critical Token Leak via Insecure Hashing Fallback in OpenClaw

OpenClaw, a personal AI assistant, interacts with third-party Large Language Model (LLM) providers by sending system prompts that often include user context. To preserve privacy, the system supports an ownerDisplay: "hash" configuration, which replaces cleartext owner identifiers (such as phone numbers or user names) with cryptographic hashes before transmission.

However, prior to version 2026.2.22, the implementation of this hashing mechanism contained a critical flaw in its key management logic. If the user did not explicitly configure a commands.ownerDisplaySecret, the application fell back to using the gateway.auth.token or gateway.remote.token as the salt for the hash operation. These tokens are high-privilege credentials used for authenticating with the OpenClaw gateway and executing administrative commands.

By using the authentication token as a salt for low-entropy inputs (like phone numbers) and transmitting the resulting hash to external entities (LLM providers), OpenClaw inadvertently exposed the token to offline cryptographic attacks. This violation of the principle of key separation transforms a privacy feature into a mechanism for credential exfiltration.

The vulnerability resides in the configuration resolution logic within the agent runners, specifically in src/agents/cli-runner/helpers.ts and embedded runner counterparts. The root cause is an insecure fallback chain implemented using the nullish coalescing operator (??) in the buildAgentSystemPrompt or helper functions.

When the system prepares the prompt context, it attempts to resolve the ownerDisplaySecret. The vulnerable code path prioritized the specific secret but dangerously fell back to sensitive authentication tokens if the specific secret was undefined. This logic effectively treated the authentication token as a dual-use secret: both for API access control and as entropy for data masking.

Technically, this manifests as a CWE-1204 (Generation of Weak Initialization Vector/Salt) and CWE-200 (Exposure of Sensitive Information). Because the output of this operation (the hashed owner ID) is sent to external servers (OpenAI, Anthropic, etc.), the secret material used to generate the hash leaves the trust boundary of the local OpenClaw instance.

The following analysis of src/agents/cli-runner/helpers.ts illustrates the insecure fallback and the subsequent remediation.

Vulnerable Code (Pre-Patch): The code directly accesses the gateway tokens if ownerDisplaySecret is missing. This tightly couples the hashing logic with administrative credentials.

// src/agents/cli-runner/helpers.ts
const ownerDisplaySecret =
  params.config?.commands?.ownerDisplaySecret ??
  params.config?.gateway?.auth?.token ??  // <--- CRITICAL: Leaks Auth Token
  params.config?.gateway?.remote?.token;  // <--- CRITICAL: Leaks Remote Token

Fixed Code (Patch 2026.2.22): The fix involves decoupling the display secret from the gateway configuration. The fallback to gateway.auth.token is removed entirely. A new helper function resolveOwnerDisplaySetting is introduced to ensure a dedicated secret exists, generating a random 32-byte buffer if necessary.

// src/agents/cli-runner/helpers.ts
import { resolveOwnerDisplaySetting } from '../utils/config';
 
// ... inside function
const ownerDisplay = resolveOwnerDisplaySetting(params.config);
 
return buildAgentSystemPrompt({
  // ... other params
  ownerDisplay: ownerDisplay.ownerDisplay,
  // FALLBACK REMOVED: Now uses a strictly dedicated secret
  ownerDisplaySecret: ownerDisplay.ownerDisplaySecret,
});

This change ensures that even if the configuration is incomplete, the system will never silently downgrade security by reusing the master authentication token.

An attacker does not need direct access to the OpenClaw instance to exploit this vulnerability; they require access to the data sent to the LLM provider or the logs thereof. This could be achieved by an attacker with access to the LLM provider's logs, a Man-in-the-Middle (MitM) attacker on the network (if TLS is compromised or terminated early), or through shared access to conversation histories.

Attack Steps:

1. Intercept Hash: The attacker obtains the hashed owner ID from the system prompt sent to the LLM. Example: Hash("+15550199", Salt).
2. Identify Input Space: The attacker identifies the likely input. Since owner IDs are often phone numbers or simple usernames, the entropy of the input is extremely low (e.g., a 10-digit phone number space is trivial to enumerate).
3. Offline Brute-Force: The attacker performs an offline dictionary or brute-force attack. They iterate through possible phone numbers and candidate salts. However, specifically here, they treat the salt as the unknown variable if they know the phone number (target), or they use the known structure of OpenClaw tokens to reduce the search space.
4. Credential Recovery: Once the hash collision is found, the Salt value is revealed. Due to the vulnerability, this Salt is the gateway.auth.token.
5. System Compromise: The attacker uses the recovered token to authenticate against the OpenClaw API, enabling them to execute arbitrary commands, modify configurations, or exfiltrate personal data.

The impact of this vulnerability is critical because it breaks the fundamental security barrier of the application: authentication.

• Confidentiality (High): The gateway.auth.token is the master key for the OpenClaw instance. Its compromise allows full read access to all stored data, conversation history, and connected integrations.
• Integrity (High): With the auth token, an attacker can modify system behavior, inject malicious instructions into the AI agent, or alter configuration files.
• Availability (High): An attacker can shut down the agent, revoke access for legitimate users, or effectively brick the installation.

CVSS v3.1 Vector: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H (Score: 9.8). The attack vector is Network, complexity is Low (once logs are accessed), and no privileges or user interaction are required.