Listen to this Post
How the CVE Works
This vulnerability exploits an authorization inconsistency between two API surfaces in OpenClaw. The WebSocket RPC control plane enforces strict scope-based access control, requiring the `operator.read` scope to call the `models.list` method. However, the OpenAI-compatible HTTP endpoint /v1/models, which performs the same function of enumerating model metadata, only validates the bearer token for authentication. It fails to enforce the equivalent `operator.read` scope check.
A malicious or compromised caller possessing only the `operator.approvals` scope (which lacks read privileges) can leverage this flaw. When connecting via WebSocket, their attempt to call `models.list` is correctly rejected with a “missing scope: operator.read” error. But when they send a simple GET request to the `/v1/models` HTTP endpoint with the same valid bearer token, the server returns a 200 OK response containing the full list of model metadata. This bypasses the intended least-privilege model, as confirmed on commit 06de515b6c42816b62ec752e1c221cab67b38501. The root cause is the failure to apply a centralized scope-authorization helper to the HTTP compatibility route, leading to policy drift between the WebSocket and HTTP interfaces.
dailycve form
Platform: OpenClaw Gateway
Version: 2026.3.23, main
Vulnerability : AuthZ bypass info
Severity: Medium
date: 2026-03-31
Prediction: Fixed version 2026.3.24
What Undercode Say:
Analytics:
The vulnerability stems from inconsistent enforcement of the `operator.read` scope. The WebSocket path uses `authorizeOperatorScopesForMethod(…)` while the HTTP path uses only token validation. This drift can be detected via static analysis by identifying all HTTP handlers that call model-listing functions but lack a scope-checking wrapper.
Bash Commands / Code:
Reproduce the vulnerability using `curl` with a token that only has operator.approvals:
Attempt models.list over WebSocket (fails)
websocat "ws://target:8080/ws" --header "Authorization: Bearer <approvals_token>" --json '{"method":"models.list"}'
Bypass via HTTP (succeeds)
curl -H "Authorization: Bearer <approvals_token>" "http://target:8080/v1/models"
Test the fix by verifying the HTTP endpoint now enforces the scope:
After patch, this should return 403 Forbidden curl -H "Authorization: Bearer <approvals_token>" "http://target:8080/v1/models" This should return 200 OK curl -H "Authorization: Bearer <read_token>" "http://target:8080/v1/models"
Exploit:
- Obtain a bearer token for an operator with only the `operator.approvals` scope.
- Send a GET request to the `/v1/models` HTTP endpoint with the token in the `Authorization` header.
- Observe the server returns a 200 OK response with the JSON list of model metadata, successfully bypassing the read-scope restriction.
Protection from this CVE
- Enforce Read Scope: Apply a scope gate equivalent to `models.list` before serving `/v1/models` and `/v1/models/:id` routes.
- Reuse Centralized Helper: Implement the same `authorizeOperatorScopesForMethod(…)` function used by the WebSocket dispatch for all HTTP compatibility endpoints to prevent policy drift.
- Add Regression Tests: Introduce negative tests ensuring a caller with `operator.approvals` (without read) is rejected on the HTTP `/v1/models` endpoint, and positive tests verifying `operator.read` is accepted on both interfaces.
Impact
- Information Disclosure: Callers lacking the `operator.read` scope can enumerate gateway model metadata via HTTP routes.
- Broken Scope Model: Inconsistent enforcement weakens the least-privilege security posture for operators granted non-read scopes.
- Privilege Escalation Path: The inconsistency can be chained with other vulnerabilities to further compromise the gateway by first mapping available models.
🎯Let’s Practice Exploiting & Learn Patching For Free:
Sources:
Reported By: github.com
Extra Source Hub:
Undercode
