GHSA-JWF4-8WF4-JF2M: Critical Authorization Bypass in OpenClaw BlueBubbles Plugin

The vulnerability resides in the plugin-sdk component of OpenClaw, specifically within the authorization logic used by the BlueBubbles optional channel extension. OpenClaw is a personal AI assistant infrastructure that aggregates communications from various platforms. The BlueBubbles plugin integrates iMessage and SMS capabilities, allowing the assistant to process and respond to messages.

The core issue is an Incorrect Authorization (CWE-863) flaw where the system defaults to an authorized state when no access policies are defined. In a secure configuration, an empty allowlist should result in all traffic being denied until explicitly permitted. However, the vulnerable implementation treated an empty list as a directive to allow all traffic, bypassing the intended pairing or allowlist security modes.

This flaw is particularly critical because pairing is often the default secure mode for new installations. Administrators expecting a 'deny-by-default' posture until devices are paired are instead left exposed to a 'permit-all' state, allowing any actor capable of routing a message to the BlueBubbles instance to interact with the AI agent.

The root cause is a logic error in the isAllowedParsedChatSender utility function located in src/plugin-sdk/allow-from.ts. This function is responsible for validating whether an incoming message sender is authorized based on the user's configuration.

The function accepts a list of allowed senders (allowFrom). The logic was intended to support a wildcard (*) for public access, but the implementation checked the length of the array to determine the default behavior. Specifically, the code contained a conditional check: if (allowFrom.length === 0). If this condition was met—meaning the user had not yet added any trusted contacts—the function returned true.

This effectively inverted the security model. Instead of failing closed (denying access when no rules exist), the system failed open. The BlueBubbles plugin relies on this boolean return value to gate access to the processMessage and processReaction workflows. Consequently, an uninitialized configuration resulted in the complete bypass of authentication checks.

The following analysis compares the vulnerable code path with the patched version in src/plugin-sdk/allow-from.ts. The fix involves inverting the return value for empty lists and requiring an explicit wildcard for open access.

Vulnerable Implementation:

export function isAllowedParsedChatSender(params: AllowedParsedChatSenderParams) {
  const allowFrom = params.allowFrom.map((entry) => String(entry).trim());
 
  // VULNERABILITY: If the list is empty, return TRUE (Allow all)
  if (allowFrom.length === 0) {
    return true;
  }
 
  // ... checks for specific sender ID ...
}

Patched Implementation (Commit 9632b9b):

export function isAllowedParsedChatSender(params: AllowedParsedChatSenderParams) {
  const allowFrom = params.allowFrom.map((entry) => String(entry).trim());
 
  // FIX: Fail-closed. If the list is empty, return FALSE (Deny all)
  if (allowFrom.length === 0) {
    return false;
  }
 
  // Explicitly require wildcard for allow-all behavior
  if (allowFrom.includes("*")) {
    return true;
  }
 
  // ... checks for specific sender ID ...
}

The patch ensures that an empty configuration results in a secure state. Additionally, logic was unified in resolveDmGroupAccessDecision to prevent similar drift in reaction processing.

Exploiting this vulnerability requires no specialized tools or authentication. The attacker simply needs to identify a target OpenClaw instance running the BlueBubbles plugin that has not yet been configured with specific trusted peers.

1. Reconnaissance: The attacker identifies the target's contact handle (e.g., phone number or email associated with the BlueBubbles/iMessage account).
2. Interaction: The attacker sends a standard text message or iMessage to the target. The message content typically includes a command understood by the AI, such as "What is my schedule?" or "Turn on the lights."
3. Bypass Execution:
   • The OpenClaw instance receives the message.
   • The BlueBubbles plugin calls isAllowedParsedChatSender.
   • Due to the unconfigured allowFrom list, the function returns true.
4. Action: The AI processes the message as if it came from a trusted administrator, executing the command and replying with the output.

The vulnerability also extends to reactions (Tapbacks), allowing an attacker to trigger event-driven workflows simply by reacting to a message history.

The impact of this vulnerability is critical due to the capabilities typically granted to personal AI assistants.

• Confidentiality Loss: Unauthorized users can query the assistant for sensitive data stored in its memory (Vector DB) or accessible via connected APIs (e.g., calendar entries, emails, notes).
• Integrity Violation: Attackers can inject false information into the assistant's memory or trigger state changes in connected systems (e.g., modifying smart home devices, sending messages on behalf of the user).
• Resource Exhaustion: An attacker can spam the assistant with complex queries, driving up LLM API costs (OpenAI, Anthropic, etc.) or exhausting local compute resources.

The CVSS score is estimated at 9.8 (Critical) because the attack vector is network-based (via the messaging platform), requires no privileges, requires no user interaction, and results in a total compromise of the confidentiality and integrity of the AI agent's operations.