GHSA-2CH6-X3G4-7759: Authorization Bypass in OpenClaw via Identity Confusion

OpenClaw is a personal AI assistant designed to integrate with various messaging platforms such as WhatsApp, Telegram, Discord, and Matrix. A core security feature of the application is its command authorization system, which restricts administrative actions (e.g., system resets, status checks, or shell execution) to specific authorized principals defined in the commands.allowFrom configuration array.

The vulnerability, identified as GHSA-2CH6-X3G4-7759, is an implementation of CWE-287 (Improper Authentication) specifically manifesting as Identity Confusion. The flaw occurs because the authorization engine fails to distinguish between an individual user's identifier (a User ID) and a conversation's identifier (a Group, Channel, or Thread ID). When processing incoming messages, the system erroneously conflates the source of the message (the conversation context) with the author of the message (the user).

This ambiguity allows for a scenario where a collective identifier is authorized, unintentionally granting individual-level privileges to every participant within that collective. Consequently, an unprivileged user within an authorized group can invoke commands that should be restricted to the bot owner or system administrators.

The root cause lies in the resolveSenderCandidates function within src/auto-reply/command-auth.ts. This function is responsible for generating a list of candidate strings that represent the message sender. These candidates are then cross-referenced against the commands.allowFrom allowlist to determine if the operation should be permitted.

In the vulnerable implementation, the function unconditionally included the ctx.From property in the candidate list. In many messaging platform adapters used by OpenClaw (specifically the WhatsApp and Telegram bridges), the ctx.From field often represents the conversation container rather than the specific user authoring the message. For example, in a WhatsApp group, ctx.From might correspond to 120363411111111111@g.us (the Group JID), while ctx.SenderId corresponds to the actual user.

Because the system treated the container ID as a valid "sender," the authorization logic became: "Is the user's ID allowlisted OR is the group's ID allowlisted?" This logic is flawed for command execution contexts, as it effectively delegates the bot's highest privilege level to an open set of users (the group members) rather than a closed set of trusted administrators.

The fix involved modifying src/auto-reply/command-auth.ts to strictly validate the nature of the identifier before treating it as a sender candidate. The patch introduces heuristics to detect conversation-like identifiers.

Vulnerable Logic (Conceptual): The original logic blindly trusted the from parameter.

// Previous implementation of resolveSenderCandidates
export function resolveSenderCandidates(params: { senderId: string, from: string, ... }) {
  const candidates = [params.senderId];
  // CRITICAL FLAW: Unconditionally adds 'from', which could be a group ID
  if (params.from) candidates.push(params.from);
  return candidates;
}

Patched Logic (Commit 08e2aa44): The patch introduces isConversationLikeIdentity to filter out known group patterns (e.g., @g.us for WhatsApp, chat_id: prefixes) and ensures from is only used if the chat type is explicitly direct.

// New utility to detect group/channel identifiers
function isConversationLikeIdentity(value: string): boolean {
  const normalized = value.trim().toLowerCase();
  // Blocks WhatsApp groups
  if (normalized.includes("@g.us")) return true;
  // Blocks generic chat IDs
  if (normalized.startsWith("chat_id:")) return true;
  // Blocks Matrix/Discord style channel identifiers
  return /(^|:)(channel|group|thread|topic|room|space|spaces):/.test(normalized);
}
 
function shouldUseFromAsSenderFallback(params: { from?: string; chatType?: string }): boolean {
  const from = (params.from ?? "").trim();
  const chatType = (params.chatType ?? "").trim().toLowerCase();
  
  // FIX 1: Only allow fallback if it is a Direct Message (DM)
  if (chatType && chatType !== "direct") return false;
  
  // FIX 2: Explicitly reject conversation-like strings
  return !isConversationLikeIdentity(from);
}

This change ensures that even if a group ID is present in the configuration, the code will refuse to resolve it as a valid sender candidate for a user command.

Exploitation relies on a misconfiguration by the administrator, which is made likely by the ambiguity of the allowFrom setting. An attacker does not need to inject code but simply needs to operate within a context that the administrator has authorized.

Scenario 1: The "Trusted Group" Fallacy

1. An administrator creates a Telegram group for "Bot Testing" and adds the OpenClaw bot.
2. Finding it tedious to add every developer's individual User ID to openclaw.json, the admin adds the Group ID (e.g., -100123456789) to commands.allowFrom, believing this restricts the bot to listening in that group.
3. Exploit: A junior developer or a compromised account within that group sends the command /exec rm -rf /.
4. Result: The bot resolves the sender candidate list. It sees the Group ID matches the allowlist. It executes the command with the bot's local system privileges.

Scenario 2: WhatsApp Group Hijacking

1. The bot is active in a public or semi-public WhatsApp group.
2. An attacker identifies the Group JID (often visible in metadata or logs).
3. The attacker socially engineers an admin to add the JID to the allowlist (e.g., "The bot isn't responding to the group, try adding the group ID").
4. Once added, any user in that WhatsApp group can issue /reset or /config commands to take over the bot infrastructure.

The impact of this vulnerability is rated High due to the potential for complete system compromise. OpenClaw is often deployed in environments with access to personal data, calendars, emails, and potentially the host server's shell (via the /exec or /shell tools, if enabled).

Confidentiality: Attackers can use commands to retrieve chat logs, personal notes, or API keys stored in the bot's memory. Integrity: Unauthorized users can modify the bot's configuration, change its behavior, or poison its knowledge base. Availability: Malicious users can issue a /reset command, wiping the bot's state, or cause a denial of service by spamming resource-intensive commands.

If the bot is running in a Docker container with mounted volumes or on a host with elevated privileges, the impact extends to the underlying infrastructure. The vulnerability essentially collapses the security model from "Authorized Users Only" to "Anyone in an Authorized Context".