https://cve.radiocsirt.org Contains only the most 10 recent entries. http://www.rssboard.org/rss-specification python-feedgen en Sat, 17 Oct 2026 14:49:14 +0000 https://cve.radiocsirt.org/vuln/ghsa-pjvx-rx66-r3fg <p><strong>Affected:</strong> npm: openclaw</p> <p>### Summary `/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.</p> <p>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.</p> <p>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.</p> <p>### Affected Packages / Versions - Package: `openclaw` (npm) - Latest published version checked: `2026.3.2` - Affected versions: `&lt;= 2026.3.2` - Fixed on `main`: March 7, 2026 in `70da80bcb5574a10925469048d2ebb2abf882e73` - Patched release: `2026.3.7`</p> <p>### Details The 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</p> <p>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.</p> <p>### Impact - Vulnerability…</p> <p><strong>Affected:</strong> npm: openclaw</p> <p>### Summary `/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.</p> <p>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.</p> <p>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.</p> <p>### Affected Packages / Versions - Package: `openclaw` (npm) - Latest published version checked: `2026.3.2` - Affected versions: `&lt;= 2026.3.2` - Fixed on `main`: March 7, 2026 in `70da80bcb5574a10925469048d2ebb2abf882e73` - Patched release: `2026.3.7`</p> <p>### Details The 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</p> <p>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.</p> <p>### Impact - Vulnerability…</p> https://cve.radiocsirt.org/vuln/ghsa-pjvx-rx66-r3fg