CVE-2026-22170

OpenClaw versions prior to 2026.2.22 with the optional BlueBubbles plugin contain an access control bypass vulnerability where empty allowFrom configuration causes dmPolicy pairing and allowlist restrictions to be ineffective. Remote attackers can send direct messages to BlueBubbles accounts by exploiting the misconfigured allowlist validation logic to bypass intended sender authorization checks.

OpenClaw versions prior to 2026.2.22 with the optional BlueBubbles plugin contain an access control bypass vulnerability where empty allowFrom configuration causes dmPolicy pairing and allowlist restrictions to be ineffective. Remote attackers can send direct messages to BlueBubbles accounts by exploiting the misconfigured allowlist validation logic to bypass intended sender authorization checks.

Summary

BlueBubbles is an optional OpenClaw channel plugin. A configuration-sensitive access-control mismatch allowed DM senders to be treated as authorized when dmPolicy was pairing or allowlist and allowFrom was empty/unset.

Severity Rationale (Medium)

Severity is set to medium because:

• this affects an optional plugin, not core messaging surfaces;
• many deployments use owner-controlled/private BlueBubbles identities with limited external reachability;
• practical exploitability depends on an untrusted sender being able to reach that specific BlueBubbles account identifier.

In typical personal/self-hosted BlueBubbles setups, the mapped Apple identity is single-owner and not broadly reachable, so this is usually low practical risk.

Risk is higher in deployments where the identifier is publicly reachable and/or agent tool permissions are broad.

Technical Details

1. BlueBubbles DM policy defaults to pairing (dmPolicy ?? "pairing").
2. Effective allowlist can be empty (effectiveAllowFrom).
3. DM/reaction authorization called isAllowedBlueBubblesSender(...).
4. That delegated to shared isAllowedParsedChatSender(...), which previously returned true for empty allowlists.
5. Result: unknown senders could bypass intended pairing/allowlist gating when allowFrom was empty.

Affected Packages / Versions

• Package: openclaw (npm)
• Vulnerable versions: <= 2026.2.21-2
• Planned fixed version: 2026.2.22

Fix

The shared parsed-chat allowlist helper now fails closed on empty allowlists, restoring expected BlueBubbles DM gating behavior. BlueBubbles inbound gating was also refactored to use one shared DM/group decision helper for both message and reaction paths to reduce future drift.

Fix Commit(s)

• 9632b9bcf032c5f2280c3103961fde912ab1f920
• 2ba6de7eaad812e5e8603018e14e54e96bdd57dd
• 51c0893673de8e5cea64e64351dbfa4680ba0dec
• 4540790cb62412676f7b61cfc6e47443f84a251e

OpenClaw thanks @tdjackey for reporting.

OpenClaw versions prior to 2026.2.22 with the optional BlueBubbles plugin contain an access control bypass vulnerability where empty allowFrom configuration causes dmPolicy pairing and allowlist restrictions to be ineffective. Remote attackers can send direct messages to BlueBubbles accounts by exploiting the misconfigured allowlist validation logic to bypass intended sender authorization checks.

OpenClaw versions prior to 2026.2.22 with the optional BlueBubbles plugin contain an access control bypass vulnerability where empty allowFrom configuration causes dmPolicy pairing and allowlist restrictions to be ineffective. Remote attackers can send direct messages to BlueBubbles accounts by exploiting the misconfigured allowlist validation logic to bypass intended sender authorization checks.

Summary

BlueBubbles is an optional OpenClaw channel plugin. A configuration-sensitive access-control mismatch allowed DM senders to be treated as authorized when dmPolicy was pairing or allowlist and allowFrom was empty/unset.

Severity Rationale (Medium)

Severity is set to medium because:

• this affects an optional plugin, not core messaging surfaces;
• many deployments use owner-controlled/private BlueBubbles identities with limited external reachability;
• practical exploitability depends on an untrusted sender being able to reach that specific BlueBubbles account identifier.

In typical personal/self-hosted BlueBubbles setups, the mapped Apple identity is single-owner and not broadly reachable, so this is usually low practical risk.

Risk is higher in deployments where the identifier is publicly reachable and/or agent tool permissions are broad.

Technical Details

1. BlueBubbles DM policy defaults to pairing (dmPolicy ?? "pairing").
2. Effective allowlist can be empty (effectiveAllowFrom).
3. DM/reaction authorization called isAllowedBlueBubblesSender(...).
4. That delegated to shared isAllowedParsedChatSender(...), which previously returned true for empty allowlists.
5. Result: unknown senders could bypass intended pairing/allowlist gating when allowFrom was empty.

Affected Packages / Versions

• Package: openclaw (npm)
• Vulnerable versions: <= 2026.2.21-2
• Planned fixed version: 2026.2.22

Fix

The shared parsed-chat allowlist helper now fails closed on empty allowlists, restoring expected BlueBubbles DM gating behavior. BlueBubbles inbound gating was also refactored to use one shared DM/group decision helper for both message and reaction paths to reduce future drift.

Fix Commit(s)

• 9632b9bcf032c5f2280c3103961fde912ab1f920
• 2ba6de7eaad812e5e8603018e14e54e96bdd57dd
• 51c0893673de8e5cea64e64351dbfa4680ba0dec
• 4540790cb62412676f7b61cfc6e47443f84a251e

OpenClaw thanks @tdjackey for reporting.