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 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.
pairing (dmPolicy ?? "pairing").effectiveAllowFrom).isAllowedBlueBubblesSender(...).isAllowedParsedChatSender(...), which previously returned true for empty allowlists.allowFrom was empty.openclaw (npm)<= 2026.2.21-22026.2.22The 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.
9632b9bcf032c5f2280c3103961fde912ab1f9202ba6de7eaad812e5e8603018e14e54e96bdd57dd51c0893673de8e5cea64e64351dbfa4680ba0dec4540790cb62412676f7b61cfc6e47443f84a251eOpenClaw thanks @tdjackey for reporting.
{
"nvd_published_at": null,
"github_reviewed_at": "2026-03-04T19:44:50Z",
"cwe_ids": [
"CWE-863"
],
"github_reviewed": true,
"severity": "MODERATE"
}