CVE-2026-35621: OpenClaw Gateway Operator.write Can Reach Admin-Class Vulnerability

HIGH
Advisory Identifier: GHSA-94pw-c6m8-p9p9
CWE-269
Published
Advisory Summary

CVE-2026-35621 is a HIGH gateway operator.write can reach admin-class vulnerability (CWE-269: Improper Privilege Management) affecting OpenClaw libraries in the npm ecosystem. The issue involves gateway operator.write can reach admin-class channel allowlist persistence via chat.send. Remediation is available by upgrading affected packages to version 2026.3.24.

CVE-2026-35621 at a Glance

CVE Identifier CVE-2026-35621
GHSA Identifier GHSA-94pw-c6m8-p9p9
Severity HIGH
CVSS v3.1 Base Score N/A
CWE Classification CWE-269: Improper Privilege Management
Affected Product OpenClaw
Package Ecosystem npm
Published Date
Last Updated

How to Fix CVE-2026-35621

To remediate this vulnerability, upgrade all affected OpenClaw dependencies to a patched release. Both direct and transitive dependencies should be checked, as frameworks or security libraries may pull in vulnerable versions transitively.

openclaw fixed: 2026.3.24
npm install openclaw@2026.3.24
Verify Direct and Transitive Dependencies

Run the following command in your project directory to verify that all resolved dependencies use the patched release:

npm ls openclaw

How to Check if You Are Affected

To determine whether your Node.js application is affected by CVE-2026-35621, inspect your project dependencies using npm:

npm ls openclaw

Analyze the terminal output to locate any version of OpenClaw in your dependency tree. If any resolved version matches the vulnerable ranges listed in the table below (for example, versions earlier than 2026.3.24), your application is affected.

Note: The npm ls openclaw command inspects dependencies declared in your package.json and lockfile; it does not perform automated runtime dynamic scanning.

Technical Details

Vulnerability Mechanism & Technical Analysis

This vulnerability is classified under CWE-269: Improper Privilege Management, where the product does not properly assign, modify, track, or check privileges for an actor, creating an unintended sphere of control for that actor. In OpenClaw, software state validation or input boundaries are circumvented during processing. Review the official source advisory statement below for specific affected components, classes, and reproduction details.

Source Advisory Statement

> Fixed in OpenClaw 2026.3.24, the current shipping release. ## Summary The shared `/allowlist` command persists channel authorization config through `writeConfigFile(...)` but does not re-validate gateway client scopes for internal gateway callers. Because `chat.send` is intentionally reachable to `operator.write` callers and still creates a generic command-authorized internal context, an authenticated write-scoped gateway client can indirectly mutate channel `allowFrom` and `groupAllowFrom` policy that direct `config.patch` correctly reserves to `operator.admin`. This is not just a generic code smell. The current code already shows the intended boundary by adding sink-side internal admin checks to shared `/config` and `/plugins` writes, but `/allowlist` was left behind. ## Details The gateway's documented scope split is clear: - `chat.send` is a write-scoped action. - direct config mutation is an admin-scoped action. The vulnerable path is: 1. A gateway client authenticates with `operator.write`. 2. The client calls `chat.send`, which is intentionally allowed for that scope. 3. `chat.send` builds an internal message context with `CommandAuthorized: true` and carries `GatewayClientScopes` into the reply pipeline. 4. `resolveCommandAuthorization(...)` converts that internal message into `isAuthorizedSender=true` in the common case where no stricter `commands.allowFrom` override is configured. 5. `/allowlist add|remove` accepts that generic command authorization and proceeds into its config-backed edit path. 6. The handler clones the parsed config, calls `plugin.allowlist.applyConfigEdit(...)`, validates the result, and persists it with `writeConfigFile(validated.config)`. 7. No sink-side check requires `operator.admin` before the persistent write occurs. That creates a direct control-plane mismatch: - `config.patch` rejects the same caller with `missing scope: operator.admin`. - `/allowlist add dm ...` or `/allowlist add group ...` reached through `chat.send` can still rewrite channel authorization state. ## Impact - A gateway client intentionally limited to `operator.write` can persist first-party channel authorization policy. - The caller can widen DM or group allowlists for channels using the shared `/allowlist` plumbing. - This weakens the repo's documented control-plane privilege split between ordinary write actions and admin-only persistent authorization mutation. ## Remediation ### 1) Add the Missing Sink-Side Internal Admin Check to `/allowlist` Mirror the existing hardened pattern from `/config` and `/plugins`. Before any config-backed `/allowlist add|remove` write, require: - `operator.admin` for internal gateway channels This should happen before `plugin.allowlist.applyConfigEdit(...)` and before `writeConfigFile(...)`. ### 2) Keep Pairing-Store and Config-Write Policy Checks, but Do Not Treat Them as Scope Enforcement `configWrites` policy and pairing-store behavior are useful secondary controls, but they do not replace the missing privilege check between `operator.write` and `operator.admin`.

CVE-2026-35621 Affected OpenClaw Versions

1 component(s)
Fixed Versions:
2026.3.24
Product / Package Ecosystem Affected Versions Fixed Version
openclaw
npm
< 2026.3.24
2026.3.24

References

Frequently Asked Questions

What is CVE-2026-35621?
CVE-2026-35621 is a security vulnerability in OpenClaw involving Gateway operator.write Can Reach Admin-Class Channel Allowlist Persistence via chat.send under CWE-269: Improper Privilege Management.
Which OpenClaw versions are affected?
Affected versions include releases prior to 2026.3.24 across affected packages: openclaw.
What version fixes CVE-2026-35621?
Upgrading to 2026.3.24 (or the latest patched release for your respective branch) resolves the vulnerability.
Is openclaw affected?
Yes, openclaw is affected in releases prior to 2026.3.24. Upgrade your dependency to 2026.3.24 or later.
What CWE is associated with CVE-2026-35621?
CVE-2026-35621 is classified under CWE-269: Improper Privilege Management (The product does not properly assign, modify, track, or check privileges for an actor, creating an unintended sphere of control for that actor.).
How can I check npm dependencies for CVE-2026-35621?
Run the dependency tree command: 'npm ls openclaw'. This command lists direct and transitive dependencies in your build configuration so you can verify if a vulnerable version is resolved.
Machine-readable OSV JSON OSV v1.5 Schema
Normalized schema output
{
  "schema_version" : "1.4.0",
  "id" : "GHSA-94pw-c6m8-p9p9",
  "modified" : "2026-04-10T17:20:19Z",
  "published" : "2026-03-30T18:52:38Z",
  "aliases" : [ "CVE-2026-35621" ],
  "summary" : "OpenClaw: Gateway operator.write Can Reach Admin-Class Channel Allowlist Persistence via chat.send",
  "details" : "> Fixed in OpenClaw 2026.3.24, the current shipping release.\n\n## Summary\n\nThe shared `/allowlist` command persists channel authorization config through `writeConfigFile(...)` but does not re-validate gateway client scopes for internal gateway callers. Because `chat.send` is intentionally reachable to `operator.write` callers and still creates a generic command-authorized internal context, an authenticated write-scoped gateway client can indirectly mutate channel `allowFrom` and `groupAllowFrom` policy that direct `config.patch` correctly reserves to `operator.admin`.\n\nThis is not just a generic code smell. The current code already shows the intended boundary by adding sink-side internal admin checks to shared `/config` and `/plugins` writes, but `/allowlist` was left behind.\n\n## Details\n\nThe gateway's documented scope split is clear:\n\n- `chat.send` is a write-scoped action.\n- direct config mutation is an admin-scoped action.\n\nThe vulnerable path is:\n\n1. A gateway client authenticates with `operator.write`.\n2. The client calls `chat.send`, which is intentionally allowed for that scope.\n3. `chat.send` builds an internal message context with `CommandAuthorized: true` and carries `GatewayClientScopes` into the reply pipeline.\n4. `resolveCommandAuthorization(...)` converts that internal message into `isAuthorizedSender=true` in the common case where no stricter `commands.allowFrom` override is configured.\n5. `/allowlist add|remove` accepts that generic command authorization and proceeds into its config-backed edit path.\n6. The handler clones the parsed config, calls `plugin.allowlist.applyConfigEdit(...)`, validates the result, and persists it with `writeConfigFile(validated.config)`.\n7. No sink-side check requires `operator.admin` before the persistent write occurs.\n\nThat creates a direct control-plane mismatch:\n\n- `config.patch` rejects the same caller with `missing scope: operator.admin`.\n- `/allowlist add dm ...` or `/allowlist add group ...` reached through `chat.send` can still rewrite channel authorization state.\n\n## Impact\n\n- A gateway client intentionally limited to `operator.write` can persist first-party channel authorization policy.\n- The caller can widen DM or group allowlists for channels using the shared `/allowlist` plumbing.\n- This weakens the repo's documented control-plane privilege split between ordinary write actions and admin-only persistent authorization mutation.\n\n## Remediation\n\n### 1) Add the Missing Sink-Side Internal Admin Check to `/allowlist`\n\nMirror the existing hardened pattern from `/config` and `/plugins`.\n\nBefore any config-backed `/allowlist add|remove` write, require:\n\n- `operator.admin` for internal gateway channels\n\nThis should happen before `plugin.allowlist.applyConfigEdit(...)` and before `writeConfigFile(...)`.\n\n### 2) Keep Pairing-Store and Config-Write Policy Checks, but Do Not Treat Them as Scope Enforcement\n\n`configWrites` policy and pairing-store behavior are useful secondary controls, but they do not replace the missing privilege check between `operator.write` and `operator.admin`.",
  "severity" : [ ],
  "affected" : [ {
    "package" : {
      "ecosystem" : "npm",
      "name" : "openclaw"
    },
    "ranges" : [ {
      "type" : "ECOSYSTEM",
      "events" : [ {
        "introduced" : "0"
      }, {
        "fixed" : "2026.3.24"
      } ]
    } ],
    "database_specific" : {
      "last_known_affected_version_range" : "<= 2026.3.23"
    }
  } ],
  "references" : [ {
    "type" : "WEB",
    "url" : "https://github.com/openclaw/openclaw/security/advisories/GHSA-94pw-c6m8-p9p9"
  }, {
    "type" : "PACKAGE",
    "url" : "https://github.com/openclaw/openclaw"
  } ],
  "database_specific" : {
    "cwe_ids" : [ "CWE-269" ],
    "severity" : "HIGH",
    "github_reviewed" : true,
    "github_reviewed_at" : "2026-03-30T18:52:38Z",
    "nvd_published_at" : null
  }
}