GHSA-pchc-86f6-8758

### 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](https://aisle.com/) for reporting.