GHSA-xp9r-prpg-373r OpenClaw: `browser.request` still allows `POST /reset-profile` through the `operator.write` surface
Fixed in OpenClaw 2026.3.24, the current shipping release.Title`browser.request` still allows `POST /reset-profile` through the `operator.write` surface in OpenClaw `v2026.3.22` after `GHSA-vmhq-cqm9-6p7q`Severity AssessmentHighCWE:`CWE-863: Incorrect Authorization`Proposed CVSS v3.1:`8.1` (`CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:H/A:H`)An 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.Likely related advisory family:`GHSA-vmhq-cqm9-6p7q`This 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.ImpactA caller with `operator.write` access to `browser.request` can still trigger persistent profile reset via `POST /reset-profile`.This crosses the intended privilege boundary for browser profile management because the release already attempts to block adjacent persistent profile mutations on this same surface.In practice, the allowed route reaches destructive behavior that can:stop the running browser for that profileclose the Playwright browser connection for that profilemove the profile's local `userDataDir` to Trash when it existsThis is a real integrity and availability impact on persistent browser state, not a route-classification mismatch with no side effects.Affected ComponentProduct:`openclaw`Tested latest released version:release tag: `v2026.3.22`release tag target commit (peeled tag): `e7d11f6c33e223a0dd8a21cfe01076bd76cef87a`Published artifact for that release:package: `openclaw-2026.3.22.tgz`package build-info commit: `4dcc39c25c6cc63fedfd004f52d173716576fcf0`package build-info timestamp: `2026-03-23T10:56:05.946Z`Exact vulnerable paths on the shipped tag:`src/gateway/method-scopes.ts:114``browser.request` is placed on the `operator.write` surface`src/gateway/server-methods/browser.ts:155-165`requests are only denied when `isPersistentBrowserProfileMutation(method, path)` returns true`src/browser/request-policy.ts:19-25`the mutation classifier recognizes `POST /profiles/create` and `DELETE /profiles/:name`, but not `POST /reset-profile``src/browser/routes/basic.ts:161-170`the browser server exposes `POST /reset-profile``src/browser/server-context.reset.ts:37-63``resetProfile()` stops the browser, closes the connection, and moves the local profile directory to Trash when present`src/node-host/invoke-browser.ts:240-243`the same route-classification helper is reused in the browser proxy path when profile restrictions are activeRelevant regression coverage gap on the shipped tag:`src/gateway/server-methods/browser.profile-from-body.test.ts:104-140`tests only block `POST /profiles/create` and `DELETE /profiles/:name`there is no equivalent deny case for `POST /reset-profile`Published artifact evidence for the exact released package:`openclaw-2026.3.22.tgz::package/dist/build-info.json``openclaw-2026.3.22.tgz::package/dist/gateway-cli-Cxz4pSoJ.js:11469-11525``openclaw-2026.3.22.tgz::package/dist/gateway-cli-Cxz4pSoJ.js:11484-11485``openclaw-2026.3.22.tgz::package/dist/request-policy-nIRryZwZ.js:9-12``openclaw-2026.3.22.tgz::package/dist/routes-CdaHRCET.js:6874-6889`Important release note:the published package build-info commit differs from the release tag target commitfor 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 pathTechnical ReproductionA direct control/exploit pair can be reproduced against the latest released version.Preconditions:use `openclaw@2026.3.22`authenticate as a caller that has access to the scoped Gateway method `browser.request`keep that caller on `operator.write`, not `operator.admin`ensure the target local browser profile existsReproduction steps:Call `browser.request` with:`method: "POST"``path: "/profiles/create"``body: { "name": "poc-profile" }`Observe the control case is rejected with:`browser.request cannot create or delete persistent browser profiles`Call `browser.request` again with:`method: "POST"``path: "/reset-profile"``body: { "profile": "poc-profile", "name": "poc-profile" }`Observe that the exploit case is not rejected by the same handler.Observe that the request is forwarded to the browser route/dispatcher, rather than being denied by the mutation classifier.Observe that the reset route succeeds and applies profile reset behavior.Why this happens in the released code:the release tries to gate persistent profile mutation using `isPersistentBrowserProfileMutation(...)`that helper does not classify `POST /reset-profile` as a protected mutationthe exposed browser server route still maps `/reset-profile` to `profileCtx.resetProfile()``resetProfile()` performs state-changing behavior on the selected local profileDemonstrated ImpactThe shipped release shows the following behavior difference:Control case:`POST /profiles/create`rejected before the request is dispatched to the browser control pathExploit case:`POST /reset-profile`not classified as a blocked mutationremains reachable through the `browser.request` surfacereaches `resetProfile()`, which performs destructive profile-management operationsThe reached route has concrete side effects:stops the running browser if activecloses the Playwright browser connectionmoves the profile's local `userDataDir` to Trash if it existsThis 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.EnvironmentEnvironment used for validation:product: `openclaw`latest released version: `2026.3.22`release tag: `v2026.3.22`release tag target commit (peeled tag): `e7d11f6c33e223a0dd8a21cfe01076bd76cef87a`published package: `openclaw-2026.3.22.tgz`published package build-info commit: `4dcc39c25c6cc63fedfd004f52d173716576fcf0`Explicit trust-model statement:this report does **not** rely on adversarial or mutually untrusted operators sharing one gateway host or configScope check:this is **not** a complaint about the existence of the explicit `browser.request` surface by itselfthis is **not** a prompt-injection-only reportthis is **not** a multi-tenant shared-gateway claimthis is **not** an attack on the unscoped HTTP compatibility endpointsthis is a concrete missed route inside an intended privilege gate on a real scoped Gateway methodthe 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 releaseRemediation AdviceRecommended fix:Extend the persistent-profile mutation classifier to include `POST /reset-profile`.Reuse the same centralized route classification everywhere the release currently relies on `isPersistentBrowserProfileMutation(...)`, including:`src/gateway/server-methods/browser.ts``src/node-host/invoke-browser.ts`Add regression coverage with both:a deny control for `POST /reset-profile` on the lower-privilege `browser.request` surfacean allow control for non-mutating browser profile readsReview nearby profile-management routes for any other state-changing endpoints that are still omitted from the mutation classifier.Treat `GHSA-vmhq-cqm9-6p7q` as the prior family and close the remaining residual route in the same policy surface.
CVSS v3.1 score: 8.1