OpenClaw BlueBubbles Group Allowlist Bypass via DM Pairing Fallback

OpenClaw is a personal AI assistant platform that integrates with various messaging services, including iMessage via the BlueBubbles bridge. The platform is designed to support granular access control policies, distinguishing between direct interactions (dmPolicy) and multi-user environments (groupPolicy). Common configurations set DMs to a pairing mode (allowing new users to authenticate) while restricting Group Chats to a strict allowlist to prevent the assistant from responding to unauthorized third parties in shared threads.

The vulnerability, identified in the BlueBubbles extension, compromises this separation of concerns. The authorization mechanism for group messages failed to strictly isolate the validation logic. Instead of solely verifying the sender against the configured group allowlist, the system checked if the sender existed in the pairing-store—a database intended to track users authenticated for private DMs. Consequently, a user who had established a trusted relationship in a private context was automatically, and incorrectly, trusted in a group context, regardless of the group's specific security policy.

This flaw represents a Classic Authorization Bypass (CWE-285) and Access Control Bypass Through User-Controlled Key (CWE-639). It undermines the integrity of the assistant's security model, as the 'key' (the pairing record) creates a transitive trust relationship that the administrator did not explicitly authorize for the group scope.

The root cause lies in the implementation of the fallback logic within the BlueBubbles message handler. OpenClaw processes incoming messages by resolving the sender's identity and checking it against the active policy for the channel type (DM vs. Group). In the vulnerable implementation, the identity resolution routine conflated the two contexts.

When a message arrived in a group channel, the system correctly identified that the groupPolicy was set to allowlist. However, if the sender's ID was not found in the groupAllowFrom list, the application did not immediately reject the request. Instead, it proceeded to check the global pairing-store. This store is designed to persist sessions for users who have completed the pairing handshake in a DM. The logic assumed that if a user is trusted enough to speak to the bot privately, they are trusted globally.

This assumption is flawed in multi-user contexts. A user might be permitted to interact with the bot privately (e.g., a friend or family member) but should not be able to trigger the bot in a group chat where the bot's responses could disrupt the conversation or leak information to other group members. The failure to enforce a 'deny by default' outcome after the allowlist check failed—and specifically the fallback to the DM-specific credential store—created the bypass condition.

The remediation involved refactoring the access policy checks to enforce strict separation between DM and Group contexts. The fallback mechanism that consulted the pairing-store during group authorization was removed entirely.

Vulnerable Logic Flow:

// Pseudo-code representation of the vulnerability
function canAccessGroup(user, groupConfig) {
  // 1. Check explicit allowlist
  if (groupConfig.allowlist.includes(user.id)) {
    return true;
  }
 
  // 2. FLAW: Fallback to DM pairing store
  // This grants access if the user is paired privately,
  // ignoring the group's restriction.
  if (pairingStore.has(user.id)) {
    return true;
  }
 
  return false;
}

Patched Logic Flow (Version 2026.2.25):

The fix ensures that group authorization relies solely on the group's configuration. The pairing-store is now exclusively queried when determining access for Direct Messages.

// Pseudo-code representation of the fix
function canAccessGroup(user, groupConfig) {
  // 1. Check explicit allowlist ONLY
  if (groupConfig.allowlist.includes(user.id)) {
    return true;
  }
 
  // No fallback. Default to deny.
  return false;
}

This change ensures that the groupPolicy is the single source of truth for group interactions, aligning the implementation with the administrator's intent.

To exploit this vulnerability, an attacker requires a valid iMessage account and the ability to interact with the target's OpenClaw instance via BlueBubbles. The attack does not require technical tooling; it relies on standard client interactions.

Step 1: Establishment of Trust (DM) The attacker initiates a Direct Message with the OpenClaw assistant. If the instance's dmPolicy is set to pairing (a common default to allow owner onboarding) or open, the attacker completes the handshake. This action creates an entry in the local pairing-store linking the attacker's handle to a trusted session.

Step 2: Group Interaction The attacker joins a Group Chat that includes the OpenClaw assistant. This group is configured with groupPolicy: allowlist, intending to restrict bot interactions solely to the owner.

Step 3: Bypass and Execution The attacker sends a command in the group chat (e.g., /bot status or a natural language query). The vulnerable OpenClaw instance checks the allowlist, fails to find the attacker, but then checks the pairing-store. Finding the valid DM session from Step 1, it authorizes the request and processes the command in the group context. This could result in the bot responding to unauthorized queries or performing actions visible to the entire group.

The impact of this vulnerability is classified as Moderate, primarily affecting Confidentiality and Integrity. While it does not grant remote code execution on the host machine directly, it allows unauthorized command execution within the context of the AI assistant.

Confidentiality: Unauthorized users in a group can query the assistant. If the assistant has access to personal data (calendars, emails, notes) or integrates with other services, this information could be retrieved and displayed in the group chat, leaking it to all participants.

Integrity: Attackers can trigger skills or actions available to the assistant. Depending on the installed extensions, this could involve sending messages, modifying connected home automation states, or altering data within the assistant's memory.

Availability: The impact on availability is low, though an attacker could potentially spam the assistant in a group setting, causing annoyance or rate-limiting issues.

The primary remediation is to upgrade the OpenClaw package. The vulnerability is patched in version 2026.2.25 and later. Users should perform the update via their package manager.

npm install openclaw@latest
# or via the CLI if available
openclaw update

Configuration Audit: Administrators should audit their openclaw.yaml configuration files. Specifically, review the channels.bluebubbles section. Ensure that groupAllowFrom contains only the numeric IDs or handles of trusted users. Users should also run the built-in doctor command to migrate any legacy username formats to stable numeric IDs, which reduces ambiguity in authorization checks.

openclaw doctor --fix

Workarounds: If an immediate update is not possible, users can mitigate the risk by setting the dmPolicy to allowlist temporarily, ensuring that only explicitly trusted users can pair even in DMs. This prevents new attackers from populating the pairing-store as a vector for group attacks, though it does not revoke access for already paired users.