GHSA-m69h-jm2f-2pv8: Authorization Bypass via Insecure Event Resolution in OpenClaw Feishu Extension

OpenClaw (formerly ClawdBot or Moltbot) operates as a personal AI assistant infrastructure, designed to integrate with various enterprise messaging platforms. The Feishu (Lark) extension specifically handles communication between the OpenClaw core logic and the Feishu platform API. This integration relies on webhooks to receive real-time updates regarding user interactions, including direct messages, group messages, and message reactions.

The vulnerability resides within the event processing subsystem of the Feishu extension. When users interact with the bot via message reactions, the system translates these interactions into synthetic message events. This abstraction allows the core bot logic to process reactions using the same command pipelines designed for text-based messages.

The core issue is an improper access control vulnerability caused by insecure default assignment. The logic responsible for determining the security context of a synthetic event fails to correctly validate the origin chat type. As a result, the system applies the least restrictive security policies to events that originate from highly restricted group environments.

This flaw primarily affects the enforcement of group-level authorization mechanisms. OpenClaw relies on Access Control Lists (ACLs) to restrict bot capabilities within specific groups, while generally allowing unrestricted interaction in direct, private channels. By circumventing the chat type classification, unauthorized users can invoke restricted bot functionalities from unauthorized group channels.

The root cause of this vulnerability is a logic flaw in the resolveReactionSyntheticEvent function, located within extensions/feishu/src/monitor.account.ts. This function is responsible for parsing incoming reaction webhooks from the Feishu API and mapping them to OpenClaw's internal event structure.

When a user reacts to a message, Feishu transmits a JSON payload containing the event details. The OpenClaw extension extracts the chat_type parameter from this payload to determine the environmental context. The system recognizes three distinct contexts: p2p (peer-to-peer), private, and group.

The vulnerable logic utilized a binary ternary operator to evaluate the chat type state. It evaluated whether the chat_type explicitly matched the string "group". If the evaluation returned false, the system automatically defaulted to "p2p". This created a dangerous fail-open condition for any unhandled or unexpected input.

Feishu API payloads can occasionally omit the chat_type field entirely during specific API scenarios or malformed requests. When the webhook payload lacked this specific attribute, the ternary evaluation failed to match "group". Consequently, the system incorrectly classified the event as a direct p2p interaction, entirely dropping the original group context.

The vulnerability stems from an insecure assumption in the TypeScript source code regarding data completeness. The system trusted the incoming webhook payload without implementing a safe fallback or strict schema validation.

Below is the vulnerable implementation extracted from extensions/feishu/src/monitor.account.ts. The strict equality check on event.chat_type forces any falsy value, including undefined, into the p2p categorization.

// Vulnerable Code: Insecure default to 'p2p'
const syntheticChatType: "p2p" | "group" | "private" = 
  event.chat_type === "group" ? "group" : "p2p";

The patch introduced in commit 3e730c0332eb0a3dc9e1e8c29a5f95e933317b41 replaces this logic with a stateful verification mechanism. Instead of relying solely on the incoming webhook payload, the system now queries the Feishu API to retrieve the authoritative metadata of the original message.

// Patched Code: Stateful verification and fail-closed logic
const fallbackChatType = reactedMsg.chatType;
const normalizedEventChatType = normalizeFeishuChatType(event.chat_type);
const resolvedChatType = normalizedEventChatType ?? fallbackChatType;
 
if (!resolvedChatType) {
    logger?.(`feishu[${accountId}]: skipping reaction ${emoji} on ${messageId} without chat type context`);
    return null; // Fail-closed: Event is dropped
}

The remediation implements three critical security controls. First, normalizeFeishuChatType ensures the payload contains a strictly valid enumerated value. Second, fallbackChatType utilizes the trusted state of the original message if the event payload is ambiguous. Finally, the conditional block enforces a strict fail-closed posture, discarding the event entirely if a valid security context cannot be established.

Exploitation of this vulnerability requires the attacker to be a member of a Feishu group chat where the target OpenClaw bot is present. The attacker does not require administrative privileges within the group, nor do they need to be on the bot's authorized user list.

The attack begins when the adversary identifies a message that the bot is programmed to monitor. The attacker then applies a specific reaction (e.g., an emoji) to this message. This action instructs the Feishu platform to generate a webhook event and transmit it to the OpenClaw application server.

To successfully bypass the authorization checks, the attacker must ensure the webhook payload processed by the bot lacks an explicit chat_type attribute. This can be achieved by leveraging specific edge cases in the Feishu API where reaction events omit contextual data, or by exploiting environments where intermediate proxies strip specific JSON fields before they reach the bot.

Once the OpenClaw server receives the manipulated or ambiguous payload, the vulnerable logic classifies the reaction as a p2p event. The bot's command dispatcher then processes the synthetic event, applying the security rules designated for direct messages. This allows the attacker to invoke commands without utilizing the required @mention syntax and bypasses the groupAllowFrom access control lists.

The primary impact of this vulnerability is an authorization bypass within the context of the Feishu messaging environment. By tricking the bot into misclassifying the event context, unauthorized users can force the bot to execute commands in restricted group channels.

OpenClaw relies on two primary security gates for group interactions: mention gating and group authorization. Mention gating ensures the bot only processes messages specifically directed at it, preventing unintended execution from casual conversation. Group authorization uses access control lists, such as the groupAllowFrom directive, to restrict bot usage to explicitly approved channels.

When a synthetic event is misclassified as p2p, both of these security gates are completely disabled. The bot processes the group reaction as if it were a direct, private command from the user. This exposes all bot functionalities that are normally shielded from the group environment.

While the vulnerability represents a complete bypass of the bot's group-level authorization mechanisms, the ultimate impact is constrained by the bot's inherent permissions. The attacker can only execute commands that the bot itself is authorized to perform within the Feishu workspace. It does not provide direct remote code execution on the underlying server, limiting the severity to moderate.

The vulnerability has been addressed in the OpenClaw npm package version 2026.3.12. Administrators are strongly advised to update their deployments to this version or newer to permanently resolve the issue. The patch fundamentally changes the event processing architecture to rely on stateful message verification rather than untrusted client payloads.

For environments where immediate patching is not feasible, administrators can implement a temporary workaround via the Feishu Developer Console. By revoking the bot's permission to read reaction events (im:message.reaction.created_v1), the attack vector is completely neutralized. This configuration change prevents the Feishu platform from sending the vulnerable webhooks to the OpenClaw server.

Security teams should actively monitor their bot application logs for anomalous reaction processing. Specifically, search the application logs for bot executions originating from group contexts where the bot was not explicitly mentioned. Repeated instances of unexpected command execution triggered by emojis or reactions may indicate active exploitation attempts.

Following the update, developers should audit their OpenClaw configuration files to ensure the groupAllowFrom directives and mention gating rules are appropriately configured. The fail-closed architecture introduced in the patch ensures that any future ambiguous events will simply be ignored, significantly reducing the attack surface.