Summary
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 Assessment
High
CWE:
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.
Affected Component
Product:
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:114browser.requestis placed on theoperator.writesurface
src/gateway/server-methods/browser.ts:155-165- requests are only denied when
isPersistentBrowserProfileMutation(method, path)returns true
- requests are only denied when
src/browser/request-policy.ts:19-25- the mutation classifier recognizes
POST /profiles/createandDELETE /profiles/:name, but notPOST /reset-profile
- the mutation classifier recognizes
src/browser/routes/basic.ts:161-170- the browser server exposes
POST /reset-profile
- the browser server exposes
src/browser/server-context.reset.ts:37-63resetProfile()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/createandDELETE /profiles/:name - there is no equivalent deny case for
POST /reset-profile
- tests only block
Published artifact evidence for the exact released package:
openclaw-2026.3.22.tgz::package/dist/build-info.jsonopenclaw-2026.3.22.tgz::package/dist/gateway-cli-Cxz4pSoJ.js:11469-11525openclaw-2026.3.22.tgz::package/dist/gateway-cli-Cxz4pSoJ.js:11484-11485openclaw-2026.3.22.tgz::package/dist/request-policy-nIRryZwZ.js:9-12openclaw-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, notoperator.admin - ensure the target local browser profile exists
Reproduction steps:
- Call
browser.requestwith: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.requestagain 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-profileas a protected mutation - the exposed browser server route still maps
/reset-profiletoprofileCtx.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.requestsurface - 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
userDataDirto 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.requestsurface 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-profileremains outside that gate in the shipped release
Remediation Advice
Recommended 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.tssrc/node-host/invoke-browser.ts
- Add regression coverage with both:
- a deny control for
POST /reset-profileon the lower-privilegebrowser.requestsurface - an allow control for non-mutating browser profile reads
- a deny control for
- Review nearby profile-management routes for any other state-changing endpoints that are still omitted from the mutation classifier.
- Treat
GHSA-vmhq-cqm9-6p7qas the prior family and close the remaining residual route in the same policy surface.
Impact
A 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 profile
- close the Playwright browser connection for that profile
- move the profile's local
userDataDirto Trash when it exists
This is a real integrity and availability impact on persistent browser state, not a route-classification mismatch with no side effects.
The application does not correctly enforce access controls, allowing a principal to access resources or operations beyond their granted permissions. Typical impact: unauthorized data access or execution of privileged operations.
CVE-2026-35653 has a CVSS score of 8.1 (High). The vector is network-reachable, low privileges required, and no user interaction. A CVSS score reflects the worst-case severity of the vulnerability, not your specific exposure. Whether this affects your application depends on whether the vulnerable code is present and reachable in your environment. A fixed version is available (2026.3.24); upgrading removes the vulnerable code path.
Affected versions
Security releases
Kodem intelligence
Severity tells you how bad this could be in the worst case. It does not tell you whether you are exposed. Exploitability and impact are functions of runtime truth: whether the vulnerable code is present, reachable, and actually executes in your application. A vulnerable package can sit in your dependency tree and never run.
Kodem, an Intelligent Application Security platform, uses runtime intelligence to reveal which vulnerabilities actually execute in production, so teams prioritize the ones that genuinely matter. Kodem's runtime-powered SCA identifies whether this CVE is reachable in your applications.
Remediation advice
Kodem Kai can prioritize this vulnerability in your dependency tree and generate a fix recommendation.
Frequently Asked Questions
- What is CVE-2026-35653? CVE-2026-35653 is a high-severity incorrect authorization vulnerability in openclaw (npm), affecting versions < 2026.3.24. It is fixed in 2026.3.24. The application does not correctly enforce access controls, allowing a principal to access resources or operations beyond their granted permissions.
- How severe is CVE-2026-35653? CVE-2026-35653 has a CVSS score of 8.1 (High). This score reflects the worst-case severity of the vulnerability, not your specific exposure. Whether it represents real risk in your environment depends on whether the vulnerable code is present and reachable.
- Which versions of openclaw are affected by CVE-2026-35653? openclaw (npm) versions < 2026.3.24 is affected.
- Is there a fix for CVE-2026-35653? Yes. CVE-2026-35653 is fixed in 2026.3.24. Upgrade to this version or later.
- Is CVE-2026-35653 exploitable, and should I be worried? Whether CVE-2026-35653 is exploitable in your environment depends on whether the vulnerable code is present and reachable. A CVSS score is a worst-case rating; it does not account for your specific deployment, configuration, or usage patterns. Kodem, an Intelligent Application Security platform, uses runtime intelligence to show which vulnerabilities actually execute in production, so you can focus on the ones that represent real risk. Get a demo
- What actually determines whether CVE-2026-35653 is exploitable, and how bad it is? Exploitability and impact are not fixed properties of a CVE. They depend on runtime truth: whether the vulnerable code is present, reachable, and actually executes in your application. A high CVSS score on a dependency that never runs is not the same as real risk. Kodem, an Intelligent Application Security platform, uses runtime intelligence to reveal which vulnerabilities actually execute in production, so teams prioritize the ones that genuinely matter.
- How do I fix CVE-2026-35653? Upgrade
openclawto 2026.3.24 or later.