GHSA-72Q8-JCMC-97WX: Authorization Bypass in openclaw via Feishu Chat Misclassification

The openclaw npm package provides integration services for the Feishu (Lark) collaboration platform. A core component of this integration is the message card action handler, which processes user interactions with interactive bot messages. This handler relies on an internal policy engine to enforce access controls, specifically separating Direct Message (DM) policies from group chat policies to restrict sensitive actions.

Versions of openclaw prior to 2026.4.20 contain an incorrect authorization vulnerability (CWE-863) within the card action classification logic. The system incorrectly infers the conversation context of synthetic message events triggered by card interactions. Because of a flawed heuristic, the internal dispatcher systematically misclassifies private DMs as group chats.

This misclassification leads to a direct bypass of the dmPolicy enforcement mechanism. When the dispatcher receives a card action from a DM, it applies the group policy ruleset instead of the intended private ruleset. This authorization bypass allows users to execute restricted commands or access bot functionalities that administrators intended to limit within private contexts.

The vulnerability stems from an unsafe logic default in the generation of synthetic message events. When a user interacts with a message card in Feishu, OpenClaw synthesizes an internal message event to process the action as a standard bot command. This process requires the system to determine the conversational context (P2P or group) to route the command to the appropriate policy engine.

The original implementation utilized a simple ternary check to determine the conversation type based on the event payload. The logic evaluated the presence of a chat_id field within the event context. If the field existed, the system assumed the conversation was a group chat.

This logic is fundamentally flawed because the Feishu API assigns a distinct chat_id to both group conversations and P2P (DM) conversations. The presence of a chat_id is not an exclusive indicator of a group chat. Consequently, the ternary condition evaluated to true for all DMs, improperly enforcing the `

The root cause exists in the initial context parsing logic. The vulnerable implementation relied entirely on implicit, unverified context clues from the webhook payload:

// Vulnerable Implementation
chat_type: event.context.chat_id ? "group" : "p2p"

The patch introduced in commit 90979d7c3ef7ec30b9f8aa6963a5e38d2f17d166 completely replaces this classification mechanism. The system now actively queries the Feishu API using the im.chat.get endpoint to retrieve the authoritative chat_mode and chat_type attributes. This eliminates reliance on the ambiguous chat_id presence check.

// Patched Implementation Snippet
async function resolveCardActionChatType(params) {
  // Cache lookup omitted for brevity
  try {
    const response = await createFeishuClient(params.account).im.chat.get({
      path: { chat_id: chatId },
    });
    if (response.code === 0) {
      const resolvedChatType =
        normalizeResolvedCardActionChatType(response.data?.chat_mode) ??
        normalizeResolvedCardActionChatType(response.data?.chat_type);
      if (resolvedChatType) {
        return resolvedChatType;
      }
    }
  } catch (err) {
    params.log(`API resolution failed: ${err.message}`);
  }
  return "p2p"; // Safe fallback
}

The updated resolveCardActionChatType function implements crucial defense-in-depth measures. It introduces an in-memory LRU cache with a 30-minute TTL to store resolved chat types, preventing API rate limiting and latency degradation. Furthermore, the logic defaults to a secure fail-closed state by returning `

The attack methodology requires the attacker to have established a direct message session with the vulnerable OpenClaw bot in a Feishu workspace. The attacker must also receive an interactive message card generated by the bot that contains actionable elements, such as buttons or form submissions.

The attacker initiates the exploit by interacting with the card element. This action triggers a webhook from the Feishu API to the OpenClaw backend. The OpenClaw handler processes the webhook payload, encounters the chat_id field assigned to the DM session, and synthesizes a message event with the chat_type explicitly set to `

The primary impact of this vulnerability is an authorization bypass affecting internal bot access controls. By tricking the policy engine into applying group chat rules to private interactions, attackers can circumvent restrictions explicitly defined in the dmPolicy configuration block.

This flaw primarily affects the confidentiality and integrity of the bot's state or the data it manages. If an administrator configured the dmPolicy to block sensitive administrative commands but permitted them in specific restricted group channels, any user interacting with a card in a DM could execute those administrative commands.

The CVSS v3.1 base score is evaluated at 5.3 (Medium). The attack vector is strictly network-based, requires low complexity, and demands no specialized privileges or active user interaction beyond the attacker interacting with the bot. The scope remains unchanged as the vulnerability does not allow escape from the bot's application context into the underlying host environment.

The immediate remediation path is upgrading the openclaw package to version 2026.4.20 or later. This version contains the comprehensive API verification logic and fail-closed state handling required to resolve the chat context accurately.

For environments where immediate patching is impossible, administrators should review existing group policies. Ensuring that group policies enforce the principle of least privilege limits the blast radius of a dmPolicy bypass. If both policies require strict authorization for sensitive actions, the impact of the misclassification is significantly reduced.

Security and operations teams must monitor Feishu bot application logs for anomalous behavior. The patched version emits a distinct log entry stating card action missing chat type for chat; defaulting to p2p when the primary resolution fails. A high frequency of these fallback events warrants investigation to ensure the API integration functions correctly.