Affected: Homebrew: openclaw-cli

### 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…

Affected: OpenClaw

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.