Skip to content

Commit 92530ae

Browse files
1 parent 3773ffd commit 92530ae

2 files changed

Lines changed: 110 additions & 0 deletions

File tree

Lines changed: 55 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,55 @@
1+
{
2+
"schema_version": "1.4.0",
3+
"id": "GHSA-39mp-545q-w789",
4+
"modified": "2026-03-30T19:06:22Z",
5+
"published": "2026-03-30T19:06:22Z",
6+
"aliases": [],
7+
"summary": "OpenClaw: Non-owner command-authorized sender can change the owner-only `/send` session delivery policy",
8+
"details": "> Fixed in OpenClaw 2026.3.24, the current shipping release.\n\n**Title** \nNon-owner command-authorized sender can change the owner-only `/send` session delivery policy\n\n**CWE** \nCWE-285 Improper Authorization\n\n**CVSS v3.1** \nCVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:L/A:L \nBase score: **5.4 (Medium)**\n\n**Severity Assessment** \nMedium. This is a real owner-only authorization bypass, but the demonstrated impact is limited to persistent mutation of the current session’s delivery policy rather than direct code execution, sandbox escape, or cross-host compromise.\n\n**Impact** \nA non-owner sender who is allowed to run commands can invoke `/send on|off|inherit` and persistently change the current session’s `sendPolicy`, even though OpenClaw documents `/send` as owner-only.\n\nThat lets a lower-trust participant:\n- disable reply delivery for the current session (`/send off`), suppressing future replies in that chat;\n- re-enable reply delivery (`/send on`) after the owner intentionally disabled it;\n- remove the session override (`/send inherit`).\n\n**Affected Component** \nVerified against the latest published GitHub release tag `v2026.3.23` (`ccfeecb6887cd97937e33a71877ad512741e82b2`), published `2026-03-23T23:15:50Z`.\n\nExact vulnerable path on the shipped tag:\n- `src/auto-reply/reply/commands-session.ts:212-239`\n - `handleSendPolicyCommand(...)` checks only `params.command.isAuthorizedSender`.\n - when true, it mutates `params.sessionEntry.sendPolicy` and persists the session entry.\n\nAuthorization behavior that makes this reachable:\n- `src/auto-reply/command-auth.ts:401-407`\n - `senderIsOwner` is computed separately from general command authorization.\n- `src/auto-reply/command-auth.ts:420-429`\n - command authorization can succeed even when `senderIsOwner === false`.\n- `src/auto-reply/command-auth.owner-default.test.ts:10-47`\n - existing coverage confirms a sender can be command-authorized while not treated as owner.\n\nDocumented owner-only contract:\n- `docs/tools/slash-commands.md:112`\n - `/send on|off|inherit` is documented as owner-only.\n- `docs/concepts/session-tool.md:156`\n - `sendPolicy` is documented as settable via `sessions.patch` or owner-only `/send on|off|inherit`.\n\nRelated privilege model:\n- `src/gateway/method-scopes.ts:131-133`\n - `sessions.patch` is admin-scoped, which reinforces that session-delivery-policy mutation is treated as privileged state.\n\nVersion history:\n- The vulnerable handler exists in release history going back at least to commit `ea018a68ccb92dbc735bc1df9880d5c95c63ca35` (`refactor(auto-reply): split reply pipeline`).\n- Earliest released affected tag found: `v2026.1.14-1`\n- Latest released affected tag verified: `v2026.3.23`\n\n**Technical Reproduction** \n1. Check out the shipped release tag `v2026.3.23`.\n2. Configure a channel where:\n - a non-owner sender is allowed to run commands, for example through `commands.allowFrom`;\n - the owner identity is distinct, for example via `commands.ownerAllowFrom`.\n3. Start or reuse a session with a live `sessionEntry` and `sessionStore`.\n4. Send `/send off` as the non-owner but command-authorized sender.\n5. Confirm the resolved command context has:\n - `isAuthorizedSender === true`\n - `senderIsOwner === false`\n6. Observe that the handler still accepts the command, mutates `sessionEntry.sendPolicy`, and persists the session entry.\n\n**Demonstrated Impact** \nThe vulnerable handler performs a real persistent session-state change:\n- `src/auto-reply/reply/commands-session.ts:232-238`\n - `/send inherit` deletes `sessionEntry.sendPolicy`\n - other modes assign `sessionEntry.sendPolicy = sendPolicyCommand.mode`\n - the handler then calls `persistSessionEntry(params)`\n\nThe mutation is not gated by owner status, only by general command authorization.\n\nThat changes subsequent delivery behavior for the current session, which matches the documented meaning of `sendPolicy`.\n\n**Environment** \n- Product: OpenClaw\n- Verified shipped tag: `v2026.3.23`\n- Shipped tag commit: `ccfeecb6887cd97937e33a71877ad512741e82b2`\n- Published GitHub release time: `2026-03-23T23:15:50Z`\n- Verification date: `2026-03-24`\n\n**Duplicate Check** \nUpon inspection there is no preexisting GHSA for `/send`.\n\nThis is distinct from:\n- `GHSA-r7vr-gr74-94p8`\n - that advisory covered owner-only authorization bypasses for `/config` and `/debug`, not `/send`.\n\nThis is the same authorization class, but a different privileged command surface that still lacks the owner check.\n\n**In Scope Check** \nThis report is in scope under `SECURITY.md` because:\n- it does **not** rely on adversarial operators sharing one gateway host or config;\n- it does **not** rely on trusted local state tampering;\n- `SECURITY.md:151-152` explicitly says non-owner sender status matters for owner-only tools and commands;\n- `/send` is explicitly documented as owner-only, so this is a direct owner-only authorization bypass, not a complaint about normal shared-agent steering.\n\nThis is therefore a concrete authorization flaw against a documented product boundary.\n\n**Remediation Advice** \n1. Change `/send` to require owner status, not just command authorization.\n2. Reuse the same owner-only rejection pattern already used by privileged command surfaces such as `/config`, `/debug`, and owner-only `/plugins` writes.\n3. Add regression coverage for the exact case where:\n - a non-owner sender is command-authorized;\n - `/send` must still be rejected unless `senderIsOwner === true`.\n4. Verify that the owner can still use `/send on|off|inherit` normally.",
9+
"severity": [
10+
{
11+
"type": "CVSS_V3",
12+
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:L/A:L"
13+
}
14+
],
15+
"affected": [
16+
{
17+
"package": {
18+
"ecosystem": "npm",
19+
"name": "openclaw"
20+
},
21+
"ranges": [
22+
{
23+
"type": "ECOSYSTEM",
24+
"events": [
25+
{
26+
"introduced": "0"
27+
},
28+
{
29+
"fixed": "2026.3.24"
30+
}
31+
]
32+
}
33+
]
34+
}
35+
],
36+
"references": [
37+
{
38+
"type": "WEB",
39+
"url": "https://github.com/openclaw/openclaw/security/advisories/GHSA-39mp-545q-w789"
40+
},
41+
{
42+
"type": "PACKAGE",
43+
"url": "https://github.com/openclaw/openclaw"
44+
}
45+
],
46+
"database_specific": {
47+
"cwe_ids": [
48+
"CWE-285"
49+
],
50+
"severity": "MODERATE",
51+
"github_reviewed": true,
52+
"github_reviewed_at": "2026-03-30T19:06:22Z",
53+
"nvd_published_at": null
54+
}
55+
}
Lines changed: 55 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,55 @@
1+
{
2+
"schema_version": "1.4.0",
3+
"id": "GHSA-xp9r-prpg-373r",
4+
"modified": "2026-03-30T19:05:11Z",
5+
"published": "2026-03-30T19:05:11Z",
6+
"aliases": [],
7+
"summary": "OpenClaw: `browser.request` still allows `POST /reset-profile` through the `operator.write` surface",
8+
"details": "> Fixed in OpenClaw 2026.3.24, the current shipping release.\n\n# Title\n\n`browser.request` still allows `POST /reset-profile` through the `operator.write` surface in OpenClaw `v2026.3.22` after `GHSA-vmhq-cqm9-6p7q`\n\n## Severity Assessment\n\nHigh\n\nCWE:\n\n- `CWE-863: Incorrect Authorization`\n\nProposed CVSS v3.1:\n\n- `8.1` (`CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:H/A:H`)\n\nAn authenticated caller who only has access to the scoped Gateway method `browser.request` on the `operator.write` surface can still reach a destructive persistent-profile management route.\n\nLikely related advisory family:\n\n- `GHSA-vmhq-cqm9-6p7q`\n\nThis should be treated as a later-version residual or incomplete fix. The earlier fix blocked `POST /profiles/create` and profile deletion, but the latest released `v2026.3.22` code still omits `POST /reset-profile` from the same mutation gate.\n\n## Impact\n\nA caller with `operator.write` access to `browser.request` can still trigger persistent profile reset via `POST /reset-profile`.\n\nThis crosses the intended privilege boundary for browser profile management because the release already attempts to block adjacent persistent profile mutations on this same surface.\n\nIn practice, the allowed route reaches destructive behavior that can:\n\n- stop the running browser for that profile\n- close the Playwright browser connection for that profile\n- move the profile's local `userDataDir` to Trash when it exists\n\nThis is a real integrity and availability impact on persistent browser state, not a route-classification mismatch with no side effects.\n\n## Affected Component\n\nProduct:\n\n- `openclaw`\n\nTested latest released version:\n\n- release tag: `v2026.3.22`\n- release tag target commit (peeled tag): `e7d11f6c33e223a0dd8a21cfe01076bd76cef87a`\n\nPublished artifact for that release:\n\n- package: `openclaw-2026.3.22.tgz`\n- package build-info commit: `4dcc39c25c6cc63fedfd004f52d173716576fcf0`\n- package build-info timestamp: `2026-03-23T10:56:05.946Z`\n\nExact vulnerable paths on the shipped tag:\n\n- `src/gateway/method-scopes.ts:114`\n - `browser.request` is placed on the `operator.write` surface\n- `src/gateway/server-methods/browser.ts:155-165`\n - requests are only denied when `isPersistentBrowserProfileMutation(method, path)` returns true\n- `src/browser/request-policy.ts:19-25`\n - the mutation classifier recognizes `POST /profiles/create` and `DELETE /profiles/:name`, but not `POST /reset-profile`\n- `src/browser/routes/basic.ts:161-170`\n - the browser server exposes `POST /reset-profile`\n- `src/browser/server-context.reset.ts:37-63`\n - `resetProfile()` stops the browser, closes the connection, and moves the local profile directory to Trash when present\n- `src/node-host/invoke-browser.ts:240-243`\n - the same route-classification helper is reused in the browser proxy path when profile restrictions are active\n\nRelevant regression coverage gap on the shipped tag:\n\n- `src/gateway/server-methods/browser.profile-from-body.test.ts:104-140`\n - tests only block `POST /profiles/create` and `DELETE /profiles/:name`\n - there is no equivalent deny case for `POST /reset-profile`\n\nPublished artifact evidence for the exact released package:\n\n- `openclaw-2026.3.22.tgz::package/dist/build-info.json`\n- `openclaw-2026.3.22.tgz::package/dist/gateway-cli-Cxz4pSoJ.js:11469-11525`\n- `openclaw-2026.3.22.tgz::package/dist/gateway-cli-Cxz4pSoJ.js:11484-11485`\n- `openclaw-2026.3.22.tgz::package/dist/request-policy-nIRryZwZ.js:9-12`\n- `openclaw-2026.3.22.tgz::package/dist/routes-CdaHRCET.js:6874-6889`\n\nImportant release note:\n\n- the published package build-info commit differs from the release tag target commit\n- for this issue, the relevant authorization and route behavior was cross-checked in both the shipped tag source and the published package bundle, and it matches semantically on the vulnerable path\n\n## Technical Reproduction\n\nA direct control/exploit pair can be reproduced against the latest released version.\n\nPreconditions:\n\n- use `openclaw@2026.3.22`\n- authenticate as a caller that has access to the scoped Gateway method `browser.request`\n- keep that caller on `operator.write`, not `operator.admin`\n- ensure the target local browser profile exists\n\nReproduction steps:\n\n1. Call `browser.request` with:\n - `method: \"POST\"`\n - `path: \"/profiles/create\"`\n - `body: { \"name\": \"poc-profile\" }`\n2. Observe the control case is rejected with:\n - `browser.request cannot create or delete persistent browser profiles`\n3. Call `browser.request` again with:\n - `method: \"POST\"`\n - `path: \"/reset-profile\"`\n - `body: { \"profile\": \"poc-profile\", \"name\": \"poc-profile\" }`\n4. Observe that the exploit case is not rejected by the same handler.\n5. Observe that the request is forwarded to the browser route/dispatcher, rather than being denied by the mutation classifier.\n6. Observe that the reset route succeeds and applies profile reset behavior.\n\nWhy this happens in the released code:\n\n- the release tries to gate persistent profile mutation using `isPersistentBrowserProfileMutation(...)`\n- that helper does not classify `POST /reset-profile` as a protected mutation\n- the exposed browser server route still maps `/reset-profile` to `profileCtx.resetProfile()`\n- `resetProfile()` performs state-changing behavior on the selected local profile\n\n## Demonstrated Impact\n\nThe shipped release shows the following behavior difference:\n\nControl case:\n\n- `POST /profiles/create`\n- rejected before the request is dispatched to the browser control path\n\nExploit case:\n\n- `POST /reset-profile`\n- not classified as a blocked mutation\n- remains reachable through the `browser.request` surface\n- reaches `resetProfile()`, which performs destructive profile-management operations\n\nThe reached route has concrete side effects:\n\n- stops the running browser if active\n- closes the Playwright browser connection\n- moves the profile's local `userDataDir` to Trash if it exists\n\nThis is therefore a concrete authorization and policy gap on a real destructive profile-management route. It is not a complaint about the existence of `browser.request` by itself.\n\n## Environment\n\nEnvironment used for validation:\n\n- product: `openclaw`\n- latest released version: `2026.3.22`\n- release tag: `v2026.3.22`\n- release tag target commit (peeled tag): `e7d11f6c33e223a0dd8a21cfe01076bd76cef87a`\n- published package: `openclaw-2026.3.22.tgz`\n- published package build-info commit: `4dcc39c25c6cc63fedfd004f52d173716576fcf0`\n\nExplicit trust-model statement:\n\n- this report does **not** rely on adversarial or mutually untrusted operators sharing one gateway host or config\n\nScope check:\n\n- this is **not** a complaint about the existence of the explicit `browser.request` surface by itself\n- this is **not** a prompt-injection-only report\n- this is **not** a multi-tenant shared-gateway claim\n- this is **not** an attack on the unscoped HTTP compatibility endpoints\n- this is a concrete missed route inside an intended privilege gate on a real scoped Gateway method\n- the control case proves the policy is intended to exist on this surface, and the exploit case proves `POST /reset-profile` remains outside that gate in the shipped release\n\n## Remediation Advice\n\nRecommended fix:\n\n1. Extend the persistent-profile mutation classifier to include `POST /reset-profile`.\n2. Reuse the same centralized route classification everywhere the release currently relies on `isPersistentBrowserProfileMutation(...)`, including:\n - `src/gateway/server-methods/browser.ts`\n - `src/node-host/invoke-browser.ts`\n3. Add regression coverage with both:\n - a deny control for `POST /reset-profile` on the lower-privilege `browser.request` surface\n - an allow control for non-mutating browser profile reads\n4. Review nearby profile-management routes for any other state-changing endpoints that are still omitted from the mutation classifier.\n5. Treat `GHSA-vmhq-cqm9-6p7q` as the prior family and close the remaining residual route in the same policy surface.",
9+
"severity": [
10+
{
11+
"type": "CVSS_V3",
12+
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:H/A:H"
13+
}
14+
],
15+
"affected": [
16+
{
17+
"package": {
18+
"ecosystem": "npm",
19+
"name": "openclaw"
20+
},
21+
"ranges": [
22+
{
23+
"type": "ECOSYSTEM",
24+
"events": [
25+
{
26+
"introduced": "0"
27+
},
28+
{
29+
"fixed": "2026.3.24"
30+
}
31+
]
32+
}
33+
]
34+
}
35+
],
36+
"references": [
37+
{
38+
"type": "WEB",
39+
"url": "https://github.com/openclaw/openclaw/security/advisories/GHSA-xp9r-prpg-373r"
40+
},
41+
{
42+
"type": "PACKAGE",
43+
"url": "https://github.com/openclaw/openclaw"
44+
}
45+
],
46+
"database_specific": {
47+
"cwe_ids": [
48+
"CWE-863"
49+
],
50+
"severity": "HIGH",
51+
"github_reviewed": true,
52+
"github_reviewed_at": "2026-03-30T19:05:11Z",
53+
"nvd_published_at": null
54+
}
55+
}

0 commit comments

Comments
 (0)