CVE-2026-32067: 
OpenClaw (formerly Moltbot or Clawdbot) vulnerability analysis and mitigation

CVE-2026-32067 is an authorization bypass vulnerability in OpenClaw (npm package) affecting all versions prior to 2026.2.26. The flaw exists in the pairing-store access control for the direct message (DM) pairing policy, allowing an attacker approved as a sender in one account to be automatically accepted in another account within multi-account deployments — without explicit approval. It was published on March 21, 2026, and a patch was released as version 2026.2.26. The CVSS v3.1 base score is 8.1 (High) (GitHub Advisory, Feedly).

The root cause is classified as CWE-863 (Incorrect Authorization): the pairing-store read/write operations were not scoped to the specific account context, meaning a pairing approval stored for one account could be read and honored by another account's DM policy check. Specifically, calls to readAllowFromStore and upsertPairingRequest used only the channel identifier (e.g., "discord", "mattermost") without including an accountId, causing the store to be shared across all accounts on the same deployment. The fix introduced a createScopedPairingAccess helper that binds both the channel and accountId to all pairing store operations, and added a CI lint rule (check-pairing-account-scope.mjs) to prevent regression. Exploitation requires low privileges (an attacker must already be an approved sender in at least one account) and network access, but no user interaction from the victim (GitHub Advisory, Patch Commit 1, Patch Commit 2).

An attacker with low privileges who has been approved as a DM sender in one account can leverage the unscoped pairing store to gain automatic acceptance in other accounts within the same multi-account OpenClaw deployment, bypassing intended authorization boundaries. This results in unauthorized access to direct messages across account boundaries, with high confidentiality and integrity impact (CVSS v3.1: C:H, I:H) and no availability impact. The vulnerability is limited to multi-account deployments; single-account installations are not affected by the cross-account bypass (GitHub Advisory, Feedly).

No public proof-of-concept exploit is known, and there is no evidence of in-the-wild exploitation at this time. The EPSS score is approximately 0.026% (very low probability of exploitation in the near term). The vulnerability is not listed in the CISA Known Exploited Vulnerabilities (KEV) catalog. Exploitation requires the attacker to already hold a valid pairing approval in at least one account on the target deployment, limiting the practical attack surface (Feedly, GitHub Advisory).

1. Reconnaissance: Identify a multi-account OpenClaw deployment running a version prior to 2026.2.26 (npm package openclaw <= 2026.2.25).
2. Obtain initial approval: Register or operate as a sender and get approved (paired) in at least one target account on the deployment — this can be done through the normal DM pairing flow on any supported channel (e.g., Discord, Mattermost, IRC).
3. Identify additional accounts: Enumerate or infer the existence of other accounts on the same multi-account deployment that share the same pairing store backend.
4. Trigger cross-account access: Send a direct message to a second account on the same deployment. Because the pairing store is not scoped by accountId, the approval from the first account is read and honored for the second account's DM policy check, granting automatic acceptance without explicit approval.
5. Access unauthorized messages: With the bypass in place, the attacker can send and receive direct messages in the second (and subsequent) accounts, accessing sensitive communications that should have required separate authorization (GitHub Advisory, Patch Commit 1).

• Logs: Unexpected DM pairing approvals for senders who were never explicitly approved in a given account; pairing store read events for an account that has no prior pairing history with a sender.
• Application Behavior: A sender appearing in the allow-from list of an account without any record of an explicit pairing approval workflow being completed for that account.
• Configuration/Store: Pairing store entries that lack an accountId scope field, or entries shared across multiple accounts for the same sender identifier (e.g., same Discord user ID approved in multiple accounts simultaneously without separate approval events).
• Network: Unusual DM traffic from a sender to multiple accounts on the same deployment shortly after being approved in only one account (GitHub Advisory).

Upgrade the OpenClaw npm package to version 2026.2.26 or later, which enforces account-scoped pairing reads and writes via the new createScopedPairingAccess helper across all supported channels. No configuration-based workaround is available for the cross-account bypass; patching is the only effective remediation. Organizations using multi-account deployments should prioritize this upgrade and, until patched, monitor for unexpected cross-account DM pairing approvals (GitHub Advisory, Patch Commit 1, Patch Commit 2).

The vulnerability was reported by researcher @tdjackey and acknowledged by the OpenClaw maintainer (steipete) in the GitHub Security Advisory. The advisory was rated "Low" severity by the project (CVSS 3.7 per the advisory's own scoring), though NVD assigned a higher CVSS v3.1 score of 8.1 (High). No significant broader media coverage or notable community debate has been observed beyond the advisory and standard CVE tracking feeds (GitHub Advisory).