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 active

Relevant 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 commit
• 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

Technical Reproduction

A direct control/exploit pair can be reproduced against the latest released version.

Preconditions:

• use [email protected]
• 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 exists

Reproduction steps:

1. Call browser.request with:
   • method: "POST"
   • path: "/profiles/create"
   • body: { "name": "poc-profile" }
2. Observe the control case is rejected with:
   • browser.request cannot create or delete persistent browser profiles
3. Call browser.request again with:
   • method: "POST"
   • path: "/reset-profile"
   • body: { "profile": "poc-profile", "name": "poc-profile" }
4. Observe that the exploit case is not rejected by the same handler.
5. Observe that the request is forwarded to the browser route/dispatcher, rather than being denied by the mutation classifier.
6. 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 mutation
• the exposed browser server route still maps /reset-profile to profileCtx.resetProfile()
• resetProfile() performs state-changing behavior on the selected local profile

Demonstrated Impact

The shipped release shows the following behavior difference:

Control case:

• POST /profiles/create
• rejected before the request is dispatched to the browser control path

Exploit case:

• POST /reset-profile
• not classified as a blocked mutation
• remains reachable through the browser.request surface
• reaches resetProfile(), which performs destructive profile-management operations

The reached route has concrete side effects:

• stops the running browser if active
• closes the Playwright browser connection
• moves the profile's local userDataDir to Trash if it exists

This 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.

Environment

Environment 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 config

Scope check:

• this is not a complaint about the existence of the explicit browser.request surface by itself
• this is not a prompt-injection-only report
• this is not a multi-tenant shared-gateway claim
• this is not an attack on the unscoped HTTP compatibility endpoints
• this is a concrete missed route inside an intended privilege gate on a real scoped Gateway method
• 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

Remediation Advice

Recommended fix:

1. Extend the persistent-profile mutation classifier to include POST /reset-profile.
2. 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
3. Add regression coverage with both:
   • a deny control for POST /reset-profile on the lower-privilege browser.request surface
   • an allow control for non-mutating browser profile reads
4. Review nearby profile-management routes for any other state-changing endpoints that are still omitted from the mutation classifier.
5. Treat GHSA-vmhq-cqm9-6p7q as the prior family and close the remaining residual route in the same policy surface.