BlueBubbles webhook auth in the optional beta iMessage plugin allowed a passwordless fallback path. In some reverse-proxy/local routing setups, this could allow unauthenticated webhook events.
extensions/bluebubbles webhook handleropenclaw/openclaw (npm)2026.2.19-2<=2026.2.19-2main; planned patched release: 2026.2.21 (>=2026.2.21)The vulnerable implementation had multiple auth branches, including a passwordless fallback with loopback/proxy heuristics.
The fix now uses one authentication codepath:
- inbound webhook token/guid must match channels.bluebubbles.password
- webhook target matching is consolidated to shared plugin-sdk logic
- BlueBubbles config validation now requires password when serverUrl is set
BlueBubbles is an optional beta iMessage plugin, and onboarding/channel-add flows already require a password. Practical exposure is mainly custom/manual configurations that omitted webhook password authentication.
>=2026.2.21, planned).?password=<password> or x-password).6b2f2811dc623e5faaf2f76afaa9279637174590283029bdea23164ab7482b320cb420d1b90df806patched_versions is pre-set to the planned next release (2026.2.21) so once npm release is out, advisory publish can proceed without additional ticket edits.
OpenClaw thanks @zpbrent for reporting.
{
"cwe_ids": [
"CWE-306"
],
"github_reviewed": true,
"severity": "MODERATE",
"github_reviewed_at": "2026-03-03T21:35:56Z",
"nvd_published_at": null
}