/allowlist ... --store resolved the selected channel accountId for reads, but store writes still dropped that accountId and wrote into the legacy unscoped pairing allowlist store.
Because default-account reads still merge legacy unscoped entries, a store entry intended for one account could silently authorize the same sender on the default account.
This is a real cross-account sender-authorization scoping bug. Severity is set to medium because exploitation requires an already-authorized user who can run /allowlist edits.
openclaw (npm)2026.3.2<= 2026.3.2main: March 7, 2026 in 70da80bcb5574a10925469048d2ebb2abf882e732026.3.7The affected path was:
- src/auto-reply/reply/commands-allowlist.ts:386-393 resolved accountId and read store state with it
- src/auto-reply/reply/commands-allowlist.ts:697-702 and src/auto-reply/reply/commands-allowlist.ts:730-733 wrote store state without passing accountId
- src/pairing/pairing-store.ts:231-234 and src/pairing/pairing-store.ts:534-554 still merged legacy unscoped allowlist entries into the default account
The fix scopes /allowlist ... --store writes to the resolved account and clears legacy default-account store entries on removal so legacy reads no longer create cross-account authorization bleed-through.
/allowlist editsdefault70da80bcb5574a10925469048d2ebb2abf882e73 — scope /allowlist ... --store writes by account and clean up legacy default-account removalsnpm 2026.3.7 was published on March 8, 2026. This advisory is fixed in the released package.
Thanks @tdjackey for reporting.
| Base score | Version | Severity | Vector |
|---|---|---|---|
| 5.4 | 3.1 | — |
|
| Type | Value |
|---|---|
| GHSA | GHSA-pjvx-rx66-r3fg ↗ |
Vulnerable version ranges and first patched releases as published by GitHub.
| Ecosystem | Package | Vulnerable range | First patched | Vulnerable functions |
|---|---|---|---|---|
| npm | openclaw | <= 2026.3.2 | 2026.3.7 | — |