GHSA-33rq-m5x2-fvgf

### Summary

In the optional Twitch channel plugin (`extensions/twitch`), `allowFrom` is documented as a hard allowlist of Twitch user IDs, but it was not enforced as a hard gate. If `allowedRoles` is unset or empty, the access control path defaulted to allow, so any Twitch user who could mention the bot could reach the agent dispatch pipeline.

**Scope note:** This only affects deployments that installed and enabled the Twitch plugin. Core OpenClaw installs that do not install/enable the Twitch plugin are not impacted.

### Affected Packages / Versions

- Package: `openclaw` (npm) - Affected: `>= 2026.1.29, < 2026.2.1` - Fixed: `>= 2026.2.1`

### Details

Affected component: Twitch plugin access control (`extensions/twitch/src/access-control.ts`).

Problematic logic in `checkTwitchAccessControl()`:

- When `allowFrom` was configured, the code returned `allowed: true` for members but did not return `allowed: false` for non-members, so execution fell through. - If `allowedRoles` was unset or empty, the function returned `allowed: true` by default, even when `allowFrom` was configured.

### Proof of Concept (PoC)

1. Install and enable the Twitch plugin. 2. Configure an `allowFrom` list, but do not set `allowedRoles` (or set it to an empty list). 3. From a different Twitch account whose user ID is NOT in `allowFrom`, send a message that mentions the bot (for example `@<botname> hello`). 4. Observe the message is processed and can trigger agent dispatch/replies despite not being allowlisted.

### Impact

Authorization bypass for operators who relied on `allowFrom` to restrict who can invoke the bot in Twitch chat. Depending on configuration (tools, routing, model costs), this could lead to unintended actions/responses and resource or cost exhaustion.

### Fix Commit(s)

- `8c7901c984866a776eb59662dc9d8b028de4f0d0`

### Workaround

Upgrade to `openclaw >= 2026.2.1`.

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