# OpenClaw: Cross-account sender authorization expansion…

📦

📦 npm

Not in CISA KEV

MEDIUM severity

# OpenClaw: Cross-account sender authorization expansion in \`/allowlist ... --store\` account scopingGHSA-pjvx-rx66-r3fg

MEDIUM [Fix: openclaw/openclaw@70da80b](https://github.com/openclaw/openclaw/commit/70da80bcb5574a10925469048d2ebb2abf882e73)

GHSA-pjvx-rx66-r3fg is a medium-severity (CVSS 5.4) vulnerability in openclaw. A fix is available for openclaw — see the affected versions and patch details below.

Published

Mar 9, 2026

Updated

Mar 9, 2026

Affected

1 pkg

Patched

1 / 1

Exploits

None indexed

Exploitation data as of Mar 9, 2026 · OSV.dev, FIRST.org (EPSS)

## Real-World Exposure

1 pkg affected

How broadly this vulnerability is actually deployed: weekly install volume shows current usage, and reverse-dependency count shows how many other packages break if it stays unpatched.

133other npm packages depend on this — each one inherits the vulnerability until it's patched upstream

`openclaw`npm

2.4Mdownloads / week

## Description

#### 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.

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.

#### Affected Packages / Versions

-   Package: `openclaw` (npm)
-   Latest published version checked: `2026.3.2`
-   Affected versions: `<= 2026.3.2`
-   Fixed on `main`: March 7, 2026 in `70da80bcb5574a10925469048d2ebb2abf882e73`
-   Patched release: `2026.3.7`

#### 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

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.

#### Impact

-   Vulnerability class: improper authorization scoping / incorrect authorization
-   Exploitation requires: an already-authorized sender who can run `/allowlist` edits
-   Security effect: unintended authorization expansion from one channel account into `default`

#### Fix Commit(s)

-   `70da80bcb5574a10925469048d2ebb2abf882e73` — scope `/allowlist ... --store` writes by account and clean up legacy default-account removals

#### Release Process Note

npm `2026.3.7` was published on March 8, 2026. This advisory is fixed in the released package.

Thanks @tdjackey for reporting.

## Affected Packages

1 total 1 fixed

Ecosystem

Package

Vulnerable range

Fix

📦npm

`openclaw` 

all versions

2026.3.7`npm install openclaw@2026.3.7`

## Detection & mitigation playbook

Open-source dependency

1.  ### Detect
    
    Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for openclaw, including transitive dependencies — a direct dependency you never call can still pull in a vulnerable version.
    
2.  ### Fix
    
    Update openclaw to 2026.3.7 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-pjvx-rx66-r3fg is resolved across your whole dependency graph.
    
3.  ### Workarounds
    
    Put an independent control in front of the weakness: restrict the affected endpoint or interface to trusted networks, require an additional authentication factor or proxy-level check, and invalidate existing sessions and credentials in case the flaw has already been used.
    

## Frequently Asked Questions

\### 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. 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. ### Affected Packages / Versions - Package:

O3 Security · Impact-Aware SCA

### Is GHSA-pjvx-rx66-r3fg in your dependencies?

Find it across npm, including transitive dependencies.

[Scan my dependencies](/book-demo) [How O3 SCA works](/impact-aware-sca)