GHSA-PJVX-RX66-R3FG: Cross-account sender authorization expansion in OpenClaw

The OpenClaw AI agent framework exposes a /allowlist command designed to manage sender authorization across different accounts and channels. This command allows administrators and authorized users to persist sender permissions to the application's pairing store via the --store flag. The system implements an account-based isolation model, ensuring that permissions granted in a secondary sub-account do not affect the primary or default account.

GHSA-PJVX-RX66-R3FG is a privilege escalation vulnerability resulting from improper account scoping during this persistence operation. The vulnerability is classified under CWE-285 (Improper Authorization) and CWE-668 (Exposure of Resource to Wrong Sphere). An attacker with authorization on any secondary account can exploit this flaw to expand their permissions across the entire OpenClaw instance.

The impact of this vulnerability is high integrity loss within the authorization model. By executing a specifically crafted /allowlist command, the attacker manipulates the underlying storage mechanism into creating a globally applicable authorization entry. The OpenClaw framework processes this entry during subsequent reloads, granting the attacker unauthorized access to the default account.

The vulnerability affects all versions of OpenClaw prior to v2026.3.7. The maintainers addressed the issue in commit 70da80bcb5574a10925469048d2ebb2abf882e73 by enforcing explicit account identification during all store write and delete operations.

The root cause of GHSA-PJVX-RX66-R3FG is a discrepancy between the authorization validation logic and the persistence layer within the OpenClaw framework. The handleAllowlistCommand function correctly identifies the executing user's accountId and verifies their permission to modify the target sub-account. However, the function fails to pass this verified accountId downstream to the persistence functions responsible for writing the configuration to disk.

The underlying persistence layer, defined in pairing-store.ts, processes the incomplete data object. Between lines 231 and 234, the storage mechanism evaluates the incoming entry. When the accountId field is omitted, the code defaults to creating an unscoped entry. This behavior exists to maintain backward compatibility with older OpenClaw installations that do not utilize multi-tenant account scoping.

The framework's default account is programmed to parse these legacy unscoped entries and merge them into its own authorization list. This implicit merging creates a critical security gap. A user restricted to a minor sub-scope can write an unscoped entry to the configuration file, bypassing the intended tenant isolation.

Upon the next system reload or file read operation, the default account encounters the attacker's unscoped entry. Because the entry lacks an explicit accountId, the default account assumes ownership. This process elevates the attacker's access rights, breaking the authorization boundaries established by the framework.

Prior to the patch, the application failed to explicitly bind the accountId to the store configuration object during write operations. The addChannelAllowFromStoreEntry and removeChannelAllowFromStoreEntry functions accepted parameters that lacked the necessary tenant context. This omission directly triggered the legacy compatibility code path in pairing-store.ts.

Commit 70da80bcb5574a10925469048d2ebb2abf882e73 introduced a new helper function named updatePairingStoreAllowlist to enforce mandatory scoping. This function ensures that the accountId is explicitly mapped from the command parameters to the persistence object.

// Patched logic for explicit scoping
const storeEntry = {
  channel: params.channelId,
  entry: params.entry,
  accountId: params.accountId, // Explicitly pass the ID
};

The patch also addressed the risk of lingering legacy entries affecting the default account. The developers introduced explicit cleanup logic during removal actions. When a removal is executed on the default account, the system now performs a targeted deletion of matching legacy unscoped entries.

// Cleanup logic for legacy entries
if (params.accountId === DEFAULT_ACCOUNT_ID) {
  await removeChannelAllowFromStoreEntry({
    channel: params.channelId,
    entry: params.entry,
    // Omitting accountId explicitly targets the legacy unscoped entry for removal
  });
}

Exploitation of GHSA-PJVX-RX66-R3FG requires the attacker to possess prior authorization on at least one sub-account within the targeted OpenClaw instance. This acts as the initial access vector, fulfilling the requirement for low privileges. The attacker must be able to interact with the framework's command interface via a supported channel, such as Telegram.

The attacker executes the /allowlist add dm --store <attacker_identity> command within their authorized context. The application validates their permission for the sub-account and proceeds to process the command. Because the --store flag triggers the vulnerable persistence path, the system writes the attacker's identity to the credential store, typically located at ~/.openclaw/credentials/telegram-allowFrom.json.

The generated JSON entry lacks the critical accountId field. Upon the next service interaction or reload, the OpenClaw default account processes the modified JSON file. It encounters the unscoped entry, assumes it belongs to the global scope, and grants the attacker full access to the primary instance environment.

This methodology successfully leverages MITRE ATT&CK technique T1548.003 (Abuse Elevation Control Mechanism). The attacker effectively bridges their restricted access into full administrative control over the OpenClaw framework without requiring complex memory corruption or authentication bypass exploits.

Successful exploitation results in a complete bypass of the intended account isolation. An actor restricted to a low-privilege environment elevates their permissions to the default account. The default account typically holds administrative control over the OpenClaw framework, allowing the attacker to interact with core services and manipulate the overarching instance configuration.

The vulnerability carries an estimated CVSS v3.1 score of 6.5, categorized as Moderate severity. The CVSS vector CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:H/A:N reflects the technical characteristics of the flaw. The attack vector is strictly network-based, utilizing the standard command interfaces exposed by the application.

The complexity of the attack is low because the exploit relies entirely on standard built-in commands. No specialized timing, memory manipulation, or unique race conditions are required. The exploit deterministically triggers the underlying logic flaw every time the --store flag is used in a vulnerable environment.

The primary impact is to the integrity of the authorization model. While confidentiality and availability remain unchanged according to the CVSS metric, the total loss of authorization integrity compromises the multi-tenant architecture. The default account assumes the identity of the attacker as an authorized entity, effectively destroying the trust boundary between accounts.

The definitive resolution for this vulnerability is upgrading the OpenClaw framework to version v2026.3.7. This release incorporates the mandatory explicit scoping logic and the cleanup mechanisms required to prevent legacy entries from compromising the default account. Administrators must ensure all nodes running the OpenClaw agent are updated.

Organizations unable to patch immediately must perform manual cleanup of the pairing store files. Administrators should inspect all JSON files within the ~/.openclaw/credentials/ directory. Any entry lacking the accountId field must be removed or manually updated to reflect the correct scope.

A valid and secure entry must explicitly define the target account. For example, an entry reading {"channel": "telegram", "entry": "12345678"} is vulnerable and should be modified to {"channel": "telegram", "entry": "12345678", "accountId": "default"} or deleted entirely.

To minimize the attack surface, administrators should restrict the number of users permitted to execute the /allowlist command, particularly with the --store flag. Utilizing strict role-based access control on secondary accounts mitigates the risk of initial access by malicious actors.