GHSA-JWF4-8WF4-JF2M

Vulnerability from github – Published: 2026-03-04 19:44 – Updated: 2026-03-04 19:44
VLAI?
Summary
OpenClaw: BlueBubbles (optional plugin) pairing/allowlist mismatch when allowFrom is empty
Details

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.

Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "npm",
        "name": "openclaw"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "2026.2.22"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-03-04T19:44:50Z",
    "nvd_published_at": null,
    "severity": "MODERATE"
  },
  "details": "### Summary\nBlueBubbles 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.\n\n### Severity Rationale (Medium)\nSeverity is set to **medium** because:\n- this affects an optional plugin, not core messaging surfaces;\n- many deployments use owner-controlled/private BlueBubbles identities with limited external reachability;\n- practical exploitability depends on an untrusted sender being able to reach that specific BlueBubbles account identifier.\n\nIn typical personal/self-hosted BlueBubbles setups, the mapped Apple identity is single-owner and not broadly reachable, so this is usually low practical risk.\n\nRisk is higher in deployments where the identifier is publicly reachable and/or agent tool permissions are broad.\n\n### Technical Details\n1. BlueBubbles DM policy defaults to `pairing` (`dmPolicy ?? \"pairing\"`).\n2. Effective allowlist can be empty (`effectiveAllowFrom`).\n3. DM/reaction authorization called `isAllowedBlueBubblesSender(...)`.\n4. That delegated to shared `isAllowedParsedChatSender(...)`, which previously returned `true` for empty allowlists.\n5. Result: unknown senders could bypass intended pairing/allowlist gating when `allowFrom` was empty.\n\n### Affected Packages / Versions\n- Package: `openclaw` (npm)\n- Vulnerable versions: `\u003c= 2026.2.21-2`\n- Planned fixed version: `2026.2.22`\n\n### Fix\nThe 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.\n\n### Fix Commit(s)\n- `9632b9bcf032c5f2280c3103961fde912ab1f920`\n- `2ba6de7eaad812e5e8603018e14e54e96bdd57dd`\n- `51c0893673de8e5cea64e64351dbfa4680ba0dec`\n- `4540790cb62412676f7b61cfc6e47443f84a251e`\n\nOpenClaw thanks @tdjackey for reporting.",
  "id": "GHSA-jwf4-8wf4-jf2m",
  "modified": "2026-03-04T19:44:50Z",
  "published": "2026-03-04T19:44:50Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/openclaw/openclaw/security/advisories/GHSA-jwf4-8wf4-jf2m"
    },
    {
      "type": "WEB",
      "url": "https://github.com/openclaw/openclaw/commit/2ba6de7eaad812e5e8603018e14e54e96bdd57dd"
    },
    {
      "type": "WEB",
      "url": "https://github.com/openclaw/openclaw/commit/4540790cb62412676f7b61cfc6e47443f84a251e"
    },
    {
      "type": "WEB",
      "url": "https://github.com/openclaw/openclaw/commit/51c0893673de8e5cea64e64351dbfa4680ba0dec"
    },
    {
      "type": "WEB",
      "url": "https://github.com/openclaw/openclaw/commit/9632b9bcf032c5f2280c3103961fde912ab1f920"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/openclaw/openclaw"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:N/VI:L/VA:N/SC:N/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "OpenClaw: BlueBubbles (optional plugin) pairing/allowlist mismatch when allowFrom is empty"
}


Log in or create an account to share your comment.




Tags
Taxonomy of the tags.


Loading…

Loading…

Loading…

Sightings

Author Source Type Date

Nomenclature

  • Seen: The vulnerability was mentioned, discussed, or observed by the user.
  • Confirmed: The vulnerability has been validated from an analyst's perspective.
  • Published Proof of Concept: A public proof of concept is available for this vulnerability.
  • Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
  • Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
  • Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
  • Not confirmed: The user expressed doubt about the validity of the vulnerability.
  • Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.


Loading…

Detection rules are retrieved from Rulezet.

Loading…

Loading…