GHSA-5JVJ-HXMH-6H6J: Authorization Bypass in OpenClaw Gateway HTTP Session History

The openclaw package provides a Gateway component responsible for managing and routing chat session data. This component exposes functionality through two distinct transport protocols: WebSockets for real-time remote procedure calls (RPC) and standard HTTP REST endpoints for state retrieval.

The vulnerability, tracked as GHSA-5JVJ-HXMH-6H6J, exists within the HTTP implementation of the session history retrieval route. It is classified as CWE-863 (Incorrect Authorization). The system enforces strict scope-based access controls on the WebSocket interface but fails to replicate these checks on the equivalent HTTP endpoints.

This inconsistency creates an authorization bypass. An attacker possessing a valid authentication token with zero or restricted scopes can query the HTTP API directly to access protected resources. The system incorrectly validates the presence of the token without verifying the permissions associated with it.

The underlying flaw stems from an architectural divergence in how authorization policies are applied across different transport layers. The OpenClaw Gateway implements a scope-based access control model where specific operations require explicit scopes, such as the operator.read scope for accessing chat transcripts.

When a client requests the chat.history resource via the WebSocket interface, the Gateway routes the request through a centralized authorization handler. This handler inspects the operator's authenticated session, extracts the granted scopes, and validates them against the required operator.read policy before executing the function.

Conversely, the HTTP route handler for /sessions/:sessionKey/history implements a disparate authorization flow. The HTTP handler validates that a well-formed Bearer token is present in the Authorization header, confirming the user's identity. However, it omits the critical secondary step of checking whether the authenticated user possesses the operator.read scope necessary to read the requested session history.

Prior to the patch, the handleSessionHistoryHttpRequest function solely relied on a middleware layer that verified token authenticity. The explicit mapping between the HTTP endpoint and the required authorization scope was missing from the route definition.

Commit 1c45123231516fa50f8cf8522ba5ff2fb2ca7aea addresses this omission by explicitly synchronizing the HTTP authorization logic with the WebSocket RPC requirements. The patch introduces a new mechanism to resolve requested operator scopes from HTTP headers.

The developers implemented a new function, resolveGatewayRequestedOperatorScopes, which parses a newly introduced custom header, x-openclaw-scopes. The handleSessionHistoryHttpRequest function was then modified to invoke authorizeOperatorScopesForMethod("chat.history", requestedScopes) before processing the request.

// PATCHED: handleSessionHistoryHttpRequest (Conceptual abstraction based on commit 1c451232)
 
export async function handleSessionHistoryHttpRequest(req, res) {
  // 1. Authenticate the token (Original logic)
  const token = verifyBearerToken(req.headers.authorization);
  
  // 2. Parse requested scopes from the new custom header (New logic)
  const requestedScopes = resolveGatewayRequestedOperatorScopes(req.headers['x-openclaw-scopes']);
  
  // 3. Explicitly verify the token holds the required scope for this method (New logic)
  const isAuthorized = authorizeOperatorScopesForMethod("chat.history", requestedScopes, token);
  
  if (!isAuthorized) {
    return res.status(403).json({
      ok: false,
      error: { type: "forbidden", message: "missing scope: operator.read" }
    });
  }
  
  // 4. Proceed with returning history
  return res.status(200).json(getHistory(req.params.sessionKey));
}

Exploiting this authorization bypass requires two prerequisites. The attacker must possess network connectivity to the OpenClaw Gateway HTTP API, and they must hold a valid Bearer token issued by the system. The token does not require any specific administrative scopes.

The attack is executed by formulating a standard HTTP GET request directed at the /sessions/:sessionKey/history endpoint. The attacker bypasses the secure WebSocket interface entirely, capitalizing on the missing scope enforcement in the REST handler.

The resulting payload is straightforward. The attacker passes their low-privileged token in the Authorization header and requests a target session key. The server responds with a 200 OK status and the complete JSON transcript of the requested chat session.

GET /sessions/agent:main:main/history HTTP/1.1
Host: gateway.openclaw.internal
Authorization: Bearer <VALID_LOW_PRIV_TOKEN>
Accept: application/json

The primary impact of this vulnerability is a breach of data confidentiality. Chat transcripts often contain sensitive information, including personally identifiable information (PII), proprietary business logic, or operational credentials shared during support sessions.

The vulnerability enables horizontal privilege escalation. A compromised low-privilege account, such as a basic user or a restricted integration bot, can view the interaction history of other users and administrators within the system.

The scope of the exposure is bounded by the nature of the endpoint. The flaw permits unauthorized read access to historical data but does not grant arbitrary write capabilities, system configuration modification, or remote code execution. The integrity and availability of the gateway service remain unaffected.

The definitive remediation strategy is to upgrade the openclaw package to version 2026.3.25 or later. This release contains the complete patch that enforces the operator.read scope on the HTTP session history route.

Deploying the patch necessitates configuration changes for client applications interacting with the HTTP API. Clients must be updated to include the new x-openclaw-scopes custom header in their requests; failure to do so will result in legitimate requests being rejected with a 403 Forbidden error.

Development teams maintaining applications built on OpenClaw should conduct a systematic review of all dual-transport routes. Any endpoint accessible via both WebSocket and HTTP must be audited to ensure authorization policies are applied uniformly across both interfaces.