GHSA-pchc-86f6-8758 OpenClaw BlueBubbles webhook auth bypass via loopback proxy trust

• npm openclaw: < 2026.2.13 → fixed in 2026.2.13 • npm @openclaw/bluebubbles: < 2026.2.13 → fixed in 2026.2.13

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.