OpenClaw BlueBubbles webhook auth bypass via loopback proxy trust
OpenClaw's BlueBubbles iMessage plugin accepted webhook requests based only on loopback TCP peer address, allowing unauthenticated injection of webhook events when exposed through a reverse proxy or via SSRF. The vulnerability was patched in version 2026.2.13.
What happened
The BlueBubbles webhook handler in OpenClaw versions before 2026.2.13 accepted authenticated webhook requests based only on the TCP peer address being loopback (127.0.0.1, ::1, ::ffff:127.0.0.1), even when the configured webhook secret was missing or incorrect.
If a deployment exposed the BlueBubbles webhook endpoint through a same-host reverse proxy, or if an attacker could reach loopback via SSRF, an unauthenticated party could inject inbound webhook events into the agent pipeline.
Governance controls
The fix hardened BlueBubbles webhook auth behind reverse proxies by only accepting passwordless webhooks for direct localhost loopback requests; proxied requests now require a password.
Documentation was updated to advise users to always set a webhook password when exposing the gateway through a reverse proxy.
Classification
Sources and evidence
This record was researched and written by the Index, based on the following original reporting.