CVE-2026-22170: Openclaw Auth Bypass Vulnerability

CVE-2026-22170 Overview

OpenClaw versions prior to 2026.2.22 with the optional BlueBubbles plugin contain an access control bypass vulnerability (CWE-863: Incorrect Authorization). When the allowFrom configuration is left empty, the dmPolicy pairing and allowlist restrictions become ineffective. Remote attackers can exploit this misconfigured allowlist validation logic to bypass intended sender authorization checks and send unauthorized direct messages to BlueBubbles accounts.

Critical Impact

Remote attackers can bypass access control restrictions to send unauthorized direct messages to BlueBubbles accounts when the allowFrom configuration is empty, potentially enabling spam, phishing, or harassment campaigns.

Affected Products

• OpenClaw versions prior to 2026.2.22 (Node.js platform)
• OpenClaw installations with the optional BlueBubbles plugin enabled
• Configurations with empty allowFrom allowlist settings

Discovery Timeline

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

Technical Details for CVE-2026-22170

Vulnerability Analysis

This vulnerability represents an authorization bypass flaw in the OpenClaw BlueBubbles plugin's sender validation mechanism. The core issue lies in how the application handles an empty allowFrom configuration array. When administrators fail to specify explicit allowed senders or intentionally leave the allowlist empty (expecting a "deny all" default behavior), the validation logic fails to enforce any restrictions whatsoever.

The impact allows unauthenticated remote attackers to send direct messages to any BlueBubbles account integrated with the vulnerable OpenClaw instance. This bypasses the intended security controls designed to restrict message senders to trusted parties only. The vulnerability affects both direct message (DM) and group access policy checks, making the dmPolicy pairing feature ineffective.

Root Cause

The root cause stems from an implicit assumption in the allow-from.ts validation function. When processing an empty allowFrom array, the original code returned false without properly distinguishing between "no configuration provided" (which should fail closed) and "empty configuration" states. This ambiguous behavior meant that empty allowlists were effectively treated as open access, rather than enforcing a secure-by-default deny policy.

The security patches introduce explicit handling for empty allowlist scenarios, implementing a "fail closed" approach where empty configurations now properly deny all requests unless explicitly configured otherwise through the emptyAllowFrom parameter.

Attack Vector

This vulnerability is exploitable over the network without authentication or user interaction. An attacker can craft and send direct messages to BlueBubbles accounts by targeting OpenClaw installations where:

1. The BlueBubbles plugin is enabled
2. The allowFrom configuration is empty or unset
3. The dmPolicy pairing feature is expected to restrict sender access

The attack requires the attacker to know or discover the target BlueBubbles account identifiers, but no special privileges or credentials are needed to exploit the vulnerability.

// Security patch in src/plugin-sdk/allow-from.ts
// Source: https://github.com/openclaw/openclaw/commit/2ba6de7eaad812e5e8603018e14e54e96bdd57dd

   chatId?: number | null;
   chatGuid?: string | null;
   chatIdentifier?: string | null;
+  emptyAllowFrom?: "deny" | "allow";
   normalizeSender: (sender: string) => string;
   parseAllowTarget: (entry: string) => TParsed;
 }): boolean {
   const allowFrom = params.allowFrom.map((entry) => String(entry).trim());
   if (allowFrom.length === 0) {
-    return false;
+    // Fail closed by default. Callers can opt into legacy "empty = allow all"
+    // behavior explicitly when a surface intentionally treats an empty list as open.
+    return params.emptyAllowFrom === "allow";
   }
   if (allowFrom.includes("*")) {
     return true;

The subsequent commit simplified this further by removing the optional legacy mode entirely:

// Final security patch in src/plugin-sdk/allow-from.ts
// Source: https://github.com/openclaw/openclaw/commit/51c0893673de8e5cea64e64351dbfa4680ba0dec

   chatId?: number | null;
   chatGuid?: string | null;
   chatIdentifier?: string | null;
-  emptyAllowFrom?: "deny" | "allow";
   normalizeSender: (sender: string) => string;
   parseAllowTarget: (entry: string) => TParsed;
 }): boolean {
   const allowFrom = params.allowFrom.map((entry) => String(entry).trim());
   if (allowFrom.length === 0) {
-    // Fail closed by default. Callers can opt into legacy "empty = allow all"
-    // behavior explicitly when a surface intentionally treats an empty list as open.
-    return params.emptyAllowFrom === "allow";
+    return false;
   }
   if (allowFrom.includes("*")) {
     return true;

Detection Methods for CVE-2026-22170

Indicators of Compromise

• Unexpected direct messages appearing in BlueBubbles accounts from unrecognized senders
• Increased volume of incoming DM requests from external or unauthorized sources
• Log entries showing message deliveries bypassing dmPolicy pairing restrictions
• Configuration files containing empty allowFrom arrays in BlueBubbles plugin settings

Detection Strategies

• Audit OpenClaw configuration files to identify empty or missing allowFrom settings in BlueBubbles plugin configurations
• Review application logs for message routing events that lack corresponding allowlist validation entries
• Implement monitoring for anomalous direct message patterns or sources not matching expected sender lists
• Deploy SentinelOne Singularity Platform to detect unauthorized access patterns and suspicious network activity targeting messaging services

Monitoring Recommendations

• Enable verbose logging for the BlueBubbles plugin to capture all sender validation decisions
• Configure alerts for direct message deliveries when the dmPolicy pairing feature should be restricting access
• Monitor for configuration drift that may result in empty allowlist configurations
• Track the number of blocked versus allowed messages to establish baseline patterns

How to Mitigate CVE-2026-22170

Immediate Actions Required

• Upgrade OpenClaw to version 2026.2.22 or later immediately
• Review current BlueBubbles plugin configurations for empty allowFrom arrays
• Explicitly configure the allowFrom setting with authorized sender identifiers
• Temporarily disable the BlueBubbles plugin if upgrade cannot be performed immediately

Patch Information

The OpenClaw maintainers have addressed this vulnerability through multiple commits that implement a "fail closed" security model for empty allowlist configurations. The fix introduces proper handling in the allow-from.ts module and adds shared DM/group access policy checks via the new dm-policy-shared.ts module.

Patched Version:2026.2.22 and later

Relevant Patches:

• GitHub Commit - Make empty allowlist behavior explicit
• GitHub Commit - Share DM/group access policy checks
• GitHub Commit - Final fix removing unused mode
• GitHub Security Advisory GHSA-jwf4-8wf4-jf2m

Workarounds

• Configure explicit entries in the allowFrom array rather than leaving it empty
• Use wildcard (*) only when intentionally allowing all senders (not recommended for production)
• Implement network-level access controls to restrict which sources can communicate with the OpenClaw instance
• Consider disabling the BlueBubbles plugin until the patch can be applied

# Configuration example - Explicitly configure allowFrom in OpenClaw config
# Ensure allowFrom is never empty - add specific allowed senders
# Example configuration snippet for BlueBubbles plugin:

# In your OpenClaw configuration file (config.yaml or similar):
bluebubbles:
  enabled: true
  allowFrom:
    - "+1234567890"           # Add specific phone numbers
    - "trusted-user@example.com"  # Or email identifiers
  # Do NOT leave allowFrom empty or undefined
  # groupAllowFrom: []  # Also configure group allowlists explicitly