OpenClaw BlueBubbles webhook auth bypass via loopback proxy trust

Summary

In affected versions, the optional BlueBubbles iMessage channel plugin could accept webhook requests as authenticated 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. This does not affect the default iMessage integration unless BlueBubbles is installed and enabled.

Affected Packages / Versions

• npm: openclaw < 2026.2.13
• npm: @openclaw/bluebubbles < 2026.2.13

Details

If a deployment exposes the BlueBubbles webhook endpoint through a same-host reverse proxy (or an attacker can reach loopback via SSRF), an unauthenticated party may be able to inject inbound webhook events into the agent pipeline.

Fix Commit(s)

• f836c385ffc746cb954e8ee409f99d079bfdcd2f
• 743f4b28495cdeb0d5bf76f6ebf4af01f6a02e5a (defense-in-depth)

Mitigations

• Set a non-empty BlueBubbles webhook password.
• Avoid deployments where a public-facing reverse proxy forwards to a loopback-bound Gateway without strong upstream authentication.

Thanks @MegaManSec (https://joshua.hu) of AISLE Research Team for reporting.