/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.
{
"github_reviewed_at": "2026-03-09T19:54:08Z",
"github_reviewed": true,
"cwe_ids": [
"CWE-639",
"CWE-863"
],
"nvd_published_at": null,
"severity": "MODERATE"
}