CVE-2026-33578: Sender Policy Bypass via Incorrect Authorization in OpenClaw Extensions

OpenClaw provides integration frameworks for various messaging platforms, including Google Chat and Zalo. Administrators configure access controls within these extensions to restrict bot interactions to specific groups and specific users within those groups. The googlechat and zalouser extensions process incoming messages and evaluate them against these predefined security policies before routing commands to the core OpenClaw processing engine.

The vulnerability, tracked as CVE-2026-33578, is categorized as CWE-863 (Incorrect Authorization). It manifests in the policy enforcement modules of the affected extensions. Specifically, the flaw affects deployments that utilize route-level group allowlists without explicitly defining corresponding sender-level allowlists.

The impact of this vulnerability is an authorization bypass that permits unauthorized users to interact with the bot. While the bot restricts its presence to allowed spaces, any user within that space can issue commands. The CVSS v3.1 score of 4.3 reflects the low privileges required and the isolated impact on confidentiality, assuming the bot's capabilities permit data retrieval.

OpenClaw implements a two-tiered authorization model for its messaging extensions. The first tier, Group/Route Gating, restricts the bot's operational context to designated spaces, channels, or groups. The second tier, Sender Allowlisting, provides granular control over which individual user accounts within those allowed spaces are permitted to invoke bot functions.

The root cause is a logic error in the state resolution function responsible for merging these two tiers. When an administrator enables a group-level allowlist but leaves the specific sender allowlist array empty, the system must determine the effective fallback policy. The intended design requires the system to maintain a default-deny posture unless a sender is explicitly approved.

In affected versions, the resolveSenderScopedGroupPolicy function incorrectly handles the empty sender array condition. Instead of enforcing the restrictive group policy, the function silently downgrades the effective state to an open policy. This state transition removes all sender-level constraints for that specific group route.

This behavior creates a vulnerability specifically when administrators rely on partial configuration states. An administrator configuring a restricted space might assume that an empty sender allowlist blocks all users by default, or they may simply stage the group configuration before populating the user list. In both scenarios, the system insecurely defaults to an open state, neutralizing the intended access controls.

The vulnerability resides in extensions/googlechat/src/monitor-access.ts and the equivalent monitoring module for the zalouser extension. The vulnerable code path evaluates the configured policies before passing the message to the command handler. The logic relies on normalizedGroupUsers, an array representing the configured sender allowlist.

The following snippet demonstrates the flawed logic in the unpatched version:

const senderGroupPolicy = resolveSenderScopedGroupPolicy({
  groupPolicy,
  groupAllowFrom: normalizedGroupUsers,
});

When normalizedGroupUsers evaluates to an empty array [], the inner logic of resolveSenderScopedGroupPolicy fails to recognize the active groupPolicy restriction and returns an open state. The patch, introduced in commit e64a881ae0fb8af18e451163f4c2d611d60cc8e4, intercepts this specific edge case before the function call.

const senderGroupPolicy =
  groupConfigResolved.allowlistConfigured && normalizedGroupUsers.length === 0
    ? groupPolicy // Preserves the "allowlist" restriction
    : resolveSenderScopedGroupPolicy({
        groupPolicy,
        groupAllowFrom: normalizedGroupUsers,
      });

The remediated code introduces a ternary operation. It first verifies if an allowlist is configured (groupConfigResolved.allowlistConfigured) and checks if the sender list is empty (normalizedGroupUsers.length === 0). If both conditions are met, the code explicitly returns the restrictive groupPolicy rather than delegating the decision to resolveSenderScopedGroupPolicy. This ensures the default-deny posture is maintained.

Exploitation of CVE-2026-33578 requires specific environmental prerequisites. The attacker must possess a valid account within the target Google Chat workspace or Zalo environment. Furthermore, the attacker must have access to a space or group where the OpenClaw bot is actively operating and configured with a route-level allowlist lacking a populated sender array.

The attack execution consists of sending standard bot commands within the affected group. The attacker does not need to craft specialized payloads or manipulate HTTP parameters. The vulnerability is triggered entirely by the backend processing of a routine message event.

Upon receiving the message, the OpenClaw extension evaluates the sender's identity against the policy configuration. Because the administrator has not defined the allowFrom or groupAllowFrom arrays, the vulnerable logic resolves the state to open. The message is subsequently passed to the core engine, which executes the requested command and returns the output to the attacker.

The immediate impact of this vulnerability is an authorization bypass resulting in unauthorized interaction with the OpenClaw bot. Attackers successfully bypass intended access controls and execute commands that should be restricted to designated personnel. The severity of the outcome scales directly with the functionality exposed by the bot.

If the bot is configured to query internal databases, retrieve sensitive documentation, or interact with external APIs, the attacker gains access to those capabilities. The confidentiality impact is rated as Low in the CVSS v3.1 vector (CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N) because the data exposure is limited to what the bot is explicitly programmed to return, rather than providing direct system-level read access.

Integrity and Availability are generally not directly impacted by the authorization bypass itself. However, if the bot exposes administrative commands or destructive functions (e.g., deleting records, modifying configurations), the attacker can leverage the bypass to affect system integrity. The base CVSS score reflects the generic capability of the flaw, but risk assessments should adjust based on the specific bot implementation.

The definitive remediation for CVE-2026-33578 is upgrading the OpenClaw application to version 2026.3.28 or later. This release incorporates the logic fix that correctly enforces group policies when sender arrays are empty. Administrators should deploy the update through standard deployment pipelines and verify the version increment in the application logs.

Organizations unable to immediately apply the patch can implement a configuration-based workaround. Administrators must review the config.groups file and ensure that every route configured with allow: true also contains at least one valid user entry in the allowFrom or groupAllowFrom arrays. Populating the array prevents the condition normalizedGroupUsers.length === 0 from occurring, thereby avoiding the vulnerable code path.

Post-remediation, security teams should audit bot interaction logs for unauthorized command execution originating from restricted groups. Analyzing historical data can determine if the vulnerability was exploited prior to patching. Look for successful command responses delivered to users who are not explicitly defined in intended access matrices.