CVE-2026-31991: Openclaw Authorization Bypass Vulnerability

CVE-2026-31991 Overview

OpenClaw versions prior to 2026.2.26 contain an authorization bypass vulnerability where Signal group allowlist policy incorrectly accepts sender identities from DM pairing-store approvals. Attackers can exploit this boundary weakness by obtaining DM pairing approval to bypass group allowlist checks and gain unauthorized group access.

Critical Impact

Attackers who obtain DM pairing approval can leverage it to bypass group allowlist authorization controls, potentially gaining unauthorized access to protected group channels and resources.

Affected Products

• OpenClaw versions prior to 2026.2.26
• OpenClaw for Node.js (all affected versions)

Discovery Timeline

• 2026-03-19 - CVE-2026-31991 published to NVD
• 2026-03-19 - Last updated in NVD database

Technical Details for CVE-2026-31991

Vulnerability Analysis

This authorization bypass vulnerability (CWE-863: Incorrect Authorization) affects OpenClaw's Signal group allowlist implementation. The core issue stems from improper boundary enforcement between direct message (DM) authentication contexts and group channel authorization contexts. When the system processes sender identities, it fails to distinguish between identities approved through the DM pairing-store mechanism and those explicitly authorized for group access via the allowlist policy.

The vulnerability allows an attacker who has been approved for DM interactions to leverage that approval to bypass group allowlist restrictions. This represents a classic authentication context confusion where credentials valid in one domain (direct messages) are incorrectly accepted in another domain (group channels) where they should not have authority.

Root Cause

The root cause lies in the improper merging of allowlist sources between DM and group authorization contexts. The original implementation used a function called mergeAllowFromSources that combined both DM pairing-store approvals and group allowlist entries without proper context separation. This caused sender identities approved through the DM pairing mechanism to leak into group authorization checks.

The vulnerability specifically affects the effectiveAllowFrom calculation, where DM pairing approvals were incorrectly included when evaluating group channel access. The fix introduces explicit separation by renaming the function to mergeDmAllowFromSources and implementing resolveEffectiveAllowFromLists to properly segregate authorization contexts.

Attack Vector

The attack exploits the network-accessible authorization boundary between DM and group contexts. An attacker must first obtain legitimate DM pairing approval with a target account. Once approved for direct message interactions, the attacker can then attempt to access group channels that should be restricted by the allowlist policy. Due to the improper boundary enforcement, the DM approval is incorrectly recognized as valid group authorization, granting the attacker unauthorized group access.

The attack requires user interaction (target must approve DM pairing) and authenticated access (attacker needs valid credentials for initial DM request), which limits the exploitation scope but still represents a significant authorization bypass when successfully executed.

// Security patch - Enforcing explicit group auth boundaries
// Source: https://github.com/openclaw/openclaw/commit/64de4b6d6ae81e269ceb4ca16f53cda99ced967a

 
   const dmPolicy = account.config.dmPolicy ?? "pairing";
   const groupPolicy = account.config.groupPolicy ?? "allowlist";
+  const configuredAllowFrom = (account.config.allowFrom ?? []).map((entry) => String(entry));
   const storeAllowFrom = await readStoreAllowFromForDmPolicy({
     provider: "bluebubbles",
     dmPolicy,

// Security patch - Separating DM and group command authorization
// Source: https://github.com/openclaw/openclaw/commit/64de4b6d6ae81e269ceb4ca16f53cda99ced967a

     const hasControlCommand = core.channel.text.hasControlCommand(rawText, cfg);
     const isControlCommand = allowTextCommands && hasControlCommand;
     const useAccessGroups = cfg.commands?.useAccessGroups !== false;
+    const commandDmAllowFrom = kind === "direct" ? effectiveAllowFrom : normalizedAllowFrom;
     const senderAllowedForCommands = isMattermostSenderAllowed({
       senderId,
       senderName,
-      allowFrom: effectiveAllowFrom,
+      allowFrom: commandDmAllowFrom,
       allowNameMatching,
     });
     const groupAllowedForCommands = isMattermostSenderAllowed({

// Security patch - Renaming function to clarify DM-specific scope
// Source: https://github.com/openclaw/openclaw/commit/8bdda7a651c21e98faccdbbd73081e79cffe8be0

-export function mergeAllowFromSources(params: {
+export function mergeDmAllowFromSources(params: {
   allowFrom?: Array<string | number>;
-  storeAllowFrom?: string[];
+  storeAllowFrom?: Array<string | number>;
   dmPolicy?: string;
 }): string[] {
   const storeEntries = params.dmPolicy === "allowlist" ? [] : (params.storeAllowFrom ?? []);

Detection Methods for CVE-2026-31991

Indicators of Compromise

• Unusual group channel access by users who have only been approved for DM pairing
• Authorization logs showing group access granted without explicit allowlist entry
• Discrepancies between DM pairing store entries and group allowlist configurations
• Unexpected sender identities appearing in group channel audit logs

Detection Strategies

• Monitor authorization decision logs for group access events where the granting mechanism references DM pairing-store
• Implement correlation rules to detect users accessing group channels who are present in DM pairing stores but absent from group allowlists
• Review access patterns for users who recently received DM pairing approval and subsequently accessed restricted groups
• Deploy application-level logging to track the authorization path taken for each group access decision

Monitoring Recommendations

• Enable verbose logging for OpenClaw's authorization subsystem, particularly around allowlist policy evaluation
• Set up alerts for group access events that occur within a short timeframe after DM pairing approval
• Periodically audit the overlap between DM pairing-store entries and group allowlist configurations
• Monitor for access attempts to sensitive group channels from senders with limited authorization scope

How to Mitigate CVE-2026-31991

Immediate Actions Required

• Upgrade OpenClaw to version 2026.2.26 or later immediately
• Review group allowlist configurations to ensure only intended senders are authorized
• Audit recent group access logs for potential exploitation of this vulnerability
• Consider temporarily restricting group access to explicitly configured allowlists while patching

Patch Information

The vendor has released patches addressing this vulnerability. The fixes enforce explicit group authorization boundaries by separating DM pairing-store approvals from group allowlist evaluations. Key patches include:

• GitHub Commit 64de4b6 - Enforces explicit group auth boundaries across channels
• GitHub Commit 8bdda7a - Keeps DM pairing allowlists out of group auth

For complete details, refer to the GitHub Security Advisory GHSA-wm8r-w8pf-2v6w.

Workarounds

• Configure groupPolicy to use strict allowlist mode and explicitly define authorized senders
• Disable the DM pairing-store feature temporarily if not critical to operations
• Implement network-level controls to restrict group channel access to known trusted sources
• Use separate OpenClaw instances for DM and group channel operations to enforce boundary isolation

# Configuration example - Enforce strict group allowlist policy
# In your OpenClaw configuration file (config.yaml or environment):

# Explicitly set group policy to strict allowlist mode
OPENCLAW_GROUP_POLICY="allowlist"

# Define explicit allowlist entries for group access (comma-separated)
OPENCLAW_GROUP_ALLOWFROM="user1@example.com,user2@example.com,trusted-service-id"

# Ensure DM policy does not automatically approve group access
OPENCLAW_DM_POLICY="pairing"