8.1

CVSS Score

3.1

-

CVSS Score

Basic Information

Concerned about an active attack path?

Talk to our security experts and see Miggo in action.

Miggo Vulnerability Database

→

GHSA-m8wm-r5vq-qjpg

GHSA-m8wm-r5vq-qjpg: Duplicate Advisory: OpenClaw: Gateway HTTP endpoints re-resolve bearer auth after SecretRef rotation

Duplicate Advisory

This advisory has been withdrawn because it is a duplicate of GHSA-xmxx-7p24-h892. This link is maintained to preserve external references.

Original Description

OpenClaw before 2026.4.15 captures resolved bearer-auth configuration at startup, allowing revoked tokens to remain valid after SecretRef rotation. Gateway HTTP and WebSocket handlers fail to re-resolve authentication per-request, enabling attackers to use rotated-out bearer tokens for unauthorized gateway access.

(GitHub Advisory)

Miggo Vulnerability Database

→

GHSA-m8wm-r5vq-qjpg

GHSA-m8wm-r5vq-qjpg:

8.1

CVSS Score

3.1

-

CVSS Score

Basic Information

Is this CVE running in your environment?

Easily map the attack path and prioritize which CVEs are a threat to your organization

Validate Exposure

Technical Details

Package Name	Ecosystem	Vulnerable Versions	First Patched Version
openclaw	npm	< 2026.4.15	2026.4.15

Technical Details

Vulnerability Intelligence
Miggo AI

Root Cause Analysis

The vulnerability, identified as GHSA-m8wm-r5vq-qjpg, exists in OpenClaw's gateway component. The root cause is the improper caching of authentication credentials. The gateway's HTTP and WebSocket handlers would resolve the bearer authentication token from a SecretRef only once at startup. This configuration was then used for the lifetime of the server process.

Consequently, if the secret (e.g., the bearer token) was rotated or revoked, the gateway would not be aware of the change. It would continue to validate incoming requests against the stale, cached token, allowing an attacker to gain unauthorized access using the old, supposedly invalid token.

The vulnerability was present in two key functions:

createGatewayHttpServer: This function, responsible for handling standard HTTP requests to endpoints like /v1/* and /tools/invoke, used the stale authentication data.
attachGatewayUpgradeHandler: This function, responsible for handling WebSocket upgrade requests (e.g., for the canvas), also used the same stale authentication data.

The patch addresses this flaw by introducing a mechanism to re-resolve the authentication credentials on a per-request basis. A new function, getResolvedAuth, is introduced and called within the request/upgrade handlers of both createGatewayHttpServer and attachGatewayUpgradeHandler. This ensures that every incoming connection is authenticated against the most up-to-date secret, effectively mitigating the vulnerability by immediately honoring credential rotation.

Vulnerable functions

createGatewayHttpServer

src/gateway/server-http.ts

This function sets up the gateway's HTTP server. The vulnerability lies within the request handler logic inside this function. Before the patch, it used a `resolvedAuth` object that was initialized only once when the server started. This meant that if the authentication token was rotated or revoked, the server would continue to accept the old, stale token for HTTP requests. The fix introduces a call to `getResolvedAuth()` for every request, ensuring the latest authentication credentials are always used.

attachGatewayUpgradeHandler

src/gateway/server-http.ts

This function attaches a handler to the HTTP server for processing WebSocket upgrade requests. Similar to `createGatewayHttpServer`, this handler was vulnerable because it used a cached `resolvedAuth` object that was not updated after startup. This allowed an attacker to use a revoked bearer token to establish a WebSocket connection. The patch corrects this by calling `getResolvedAuth()` for each upgrade request, thereby re-validating the token against the current configuration.

Vulnerability Intelligence
Miggo AI

Unlock WAF rules for this CVE

Generate vendor-ready rules for the observed attack patterns, plus reasoning and safe deployment guidance

Get WAF rules

WAF Protection Rules

WAF Rule

W** rul*s *v*il**l* *or Mi**o *ustom*rs only.W** rul*s *v*il**l* *or Mi**o *ustom*rs only.W** rul*s *v*il**l* *or Mi**o *ustom*rs only.W** rul*s *v*il**l* *or Mi**o *ustom*rs only.W** rul*s *v*il**l* *or Mi**o *ustom*rs only.W** rul*s *v*il**l* *or Mi**o *ustom*rs only.W** rul*s *v*il**l* *or Mi**o *ustom*rs only.W** rul*s *v*il**l* *or Mi**o *ustom*rs only.W** rul*s *v*il**l* *or Mi**o *ustom*rs only.W** rul*s *v*il**l* *or Mi**o *ustom*rs only.

Reasoning

*v*il**l* *or Mi**o *ustom*rs only.*v*il**l* *or Mi**o *ustom*rs only.*v*il**l* *or Mi**o *ustom*rs only.*v*il**l* *or Mi**o *ustom*rs only.*v*il**l* *or Mi**o *ustom*rs only.*v*il**l* *or Mi**o *ustom*rs only.*v*il**l* *or Mi**o *ustom*rs only.*v*il**l* *or Mi**o *ustom*rs only.*v*il**l* *or Mi**o *ustom*rs only.*v*il**l* *or Mi**o *ustom*rs only.