GHSA-f6h3-846h-2r8w: Authorization Bypass in OpenClaw via Improper Recipient Validation

OpenClaw serves as an AI agent gateway, processing messages from various platforms (e.g., WhatsApp, Discord) and executing tool-based actions. To protect sensitive functionality, the system implements an "elevated mode" restricted to specific users defined in the tools.elevated.allowFrom configuration setting. This setting is intended to act as an allowlist of trusted sender identifiers (phone numbers, user IDs).

The vulnerability exists within the logic that verifies whether a sender is authorized to access this elevated mode. Instead of strictly validating the sender's identity against the allowlist, the system gathered a collection of "tokens" from the message context—including the recipient's address (ctx.To)—and checked if any of these tokens appeared in the configuration. This architectural flaw means that the identity of the target (the bot) effectively vouches for the identity of the requester.

Consequently, if an administrator adds the bot's own identifier to the allowlist (often done to allow the bot to invoke its own internal tools or during testing), the authorization check effectively defaults to true for all incoming messages directed to that bot. This bypasses authentication entirely, exposing privileged tools to the public internet.

The root cause lies in the implementation of the isApprovedElevatedSender function located in src/auto-reply/reply/reply-elevated.ts. The function was designed to offer flexibility by matching against multiple potential identifiers for a user, such as their username, display name, or unique ID. However, the implementation was overly broad in its scope of "identity candidates."

Specifically, the logic constructed a set of tokens derived from the incoming message context (MsgContext). This set erroneously included ctx.To, which represents the recipient of the message (the OpenClaw instance itself). When the authorization loop runs, it iterates through the configured allowFrom strings and checks if any of them exist in the token set.

Furthermore, the logic failed to distinguish between immutable, verified identifiers (like SenderId or E.164 phone numbers) and mutable, user-controlled metadata (like SenderName or SenderUsername). This lack of type safety meant that even without the ctx.To flaw, an attacker could potentially spoof a trusted user's display name to gain access if the configuration relied on non-unique identifiers.

The vulnerability is best understood by examining the authorization logic before and after the patch. The flawed implementation incorrectly conflated message targets with message sources.

Vulnerable Logic (Conceptual):

// The set includes the sender AND the recipient (ctx.To)
const identityTokens = [
  ctx.From,
  ctx.To, // <--- CRITICAL FLAW: The bot's own ID is included here
  ctx.SenderName,
  ctx.SenderID
];
 
// If the config allows the bot's ID, this returns true for EVERYONE
return config.allowFrom.some(allowed => identityTokens.includes(allowed));

Patched Logic (Commit 6817c0e): In the patched version, the developers removed the recipient field from the validation scope and introduced strict prefixing to bind allowlist entries to specific field types.

// 1. ctx.To is removed from the check
// 2. Strict prefixes are enforced for mutable fields
// 3. Unprefixed entries ONLY match immutable IDs
 
function isApproved(ctx, allowList) {
  for (const allowed of allowList) {
    // Implicitly pins to verified IDs if no prefix is present
    if (!allowed.includes(':')) {
       if (ctx.SenderId === allowed || ctx.From === allowed) return true;
       continue;
    }
    
    // Requires explicit opt-in for mutable fields
    if (allowed.startsWith('name:') && ctx.SenderName === allowed.slice(5)) return true;
    // ... other checks
  }
  return false;
}

The fix ensures that the allowFrom list is compared strictly against sender attributes, and ambiguous strings are treated as verified IDs by default, preventing spoofing via display names.

Exploitation of this vulnerability requires no specialized tools, only knowledge of the target's configuration state. The attack vector is strictly logic-based.

Prerequisites: The target OpenClaw instance must have the bot's own identifier (e.g., its WhatsApp phone number +15550199 or Discord Bot ID) present in the tools.elevated.allowFrom array in config.json.

Attack Steps:

1. Identification: The attacker interacts with the bot to determine if it is running a vulnerable version (e.g., via generic responses or version headers if available).
2. Triggering: The attacker sends a command that requires elevated permissions. For example: /elevated exec "cat /etc/passwd".
3. Bypass Execution: The OpenClaw instance receives the message. It extracts the To field (e.g., +15550199). It checks allowFrom. Finding +15550199 in the allowed list, it successfully validates the request, ignoring the fact that the sender is +1999666000 (the attacker).
4. Impact: The command executes with the permissions of the OpenClaw process, returning the output to the attacker.

The impact of this vulnerability is critical as it constitutes a complete authentication bypass for the most privileged functionality within the application. OpenClaw is designed to interface with LLMs and execute tools; granting unauthorized access to the "elevated" toolset typically exposes the underlying host.

• Remote Code Execution (RCE): If the elevated tools include shell execution or script running capabilities (common in AI agent deployments), an attacker can execute arbitrary commands on the server.
• Data Exfiltration: Attackers can access sensitive data accessible to the bot, including conversation logs, API keys stored in environment variables, or connected database credentials.
• Bot Hijacking: The attacker can use the compromised bot to send fraudulent messages to other users, potentially leveraging the bot's trusted status for social engineering or phishing campaigns.

Given the ease of exploitation and the high probability of the vulnerable configuration (adding the bot to the allowlist for self-testing is a common pattern), this issue represents a severe risk to deployments.