GHSA-xq8g-hgh6-87hv: Missing Rate Limiting in OpenClaw BlueBubbles Webhook Enables Brute-Force Attacks

The openclaw npm package provides a BlueBubbles extension designed to process incoming webhooks. The webhook endpoint relies on a static authentication mechanism, evaluating a password supplied via query parameters or HTTP headers. Prior to version 2026.3.25, the application lacked any mechanism to throttle or limit repeated failed authentication attempts.

This architectural oversight is classified as CWE-307 (Improper Restriction of Excessive Authentication Attempts). Without rate limiting, the authentication interface operates at the maximum speed the underlying network and hardware can support.

An unauthenticated remote attacker can exploit this flaw to execute brute-force attacks against the webhook endpoint. If a weak or predictable password is in use, the attacker can reliably compromise the endpoint, gaining unauthorized access to process messages or access OpenClaw data.

The vulnerability exists within the handleBlueBubblesWebhookRequest function located in the extensions/bluebubbles/src/monitor.ts module. When processing incoming HTTP POST requests, the function extracts the provided password from either query parameters (such as guid or password) or HTTP headers (such as x-guid or Authorization).

The function immediately evaluates the extracted credential against the configured expected password. If the provided credential does not match, the application returns an HTTP 401 Unauthorized response. The application did not track the state of client IP addresses, nor did it record the frequency of failed authentication requests.

Because the rejection was stateless and synchronous, an attacker received immediate feedback on the validity of a password guess. The absence of a delay mechanism or a lockout threshold allowed the authentication endpoint to function as a high-speed oracle for password validity.

The vulnerability was remediated in commit 5e08ce36d522a1c96df2bfe88e39303ae2643d92. The developer introduced a comprehensive fixed-window rate limiter utilizing the createFixedWindowRateLimiter function.

To ensure accurate tracking across network topologies, the patch implements a resolveWebhookClientIp utility. This utility parses X-Forwarded-For and X-Real-IP headers to identify the true client origin, provided the trustedProxies configuration is correctly established at the gateway layer.

The rate-limiting bucket is keyed using a combination of the normalized target path and the resolved client IP address (${normalizedPath}:${clientIp}). This prevents an attacker from bypassing the limit by rotating through different endpoints.

const rateLimitKey = `${normalizedPath}:${clientIp}`;
return await withResolvedWebhookRequestPipeline({
  req,
  res,
  targetsByPath: webhookTargets,
  allowMethods: ["POST"],
  rateLimiter: webhookRateLimiter,
  rateLimitKey,
  // ... other configs
});

The withResolvedWebhookRequestPipeline middleware evaluates the request rate before execution reaches the authentication logic. If the threshold is exceeded, the pipeline halts execution and returns an HTTP 429 Too Many Requests status.

An attacker initiates the exploit by directing a high volume of HTTP POST requests to the exposed BlueBubbles webhook endpoint. The attacker iteratively cycles through a dictionary of common passwords, injecting the payload into the Authorization header or the guid query parameter.

Because the vulnerable application responds with an immediate 401 Unauthorized status upon failure, the attacker uses the HTTP response code to confirm an incorrect guess. The attack continues until the server returns an HTTP 200 OK status, indicating a successful credential match.

While a standalone public exploit is not documented, the OpenClaw security test suite (monitor.webhook-auth.test.ts) serves as a practical proof-of-concept. The test executes 130 rapid authentication guesses against the patched server, verifying that the response correctly transitions from 401 Unauthorized to 429 Too Many Requests.

Administrators must upgrade the openclaw package to version 2026.3.25 or later to mitigate this vulnerability. The applied patch enforces a default budget of approximately 120 requests per minute per IP address.

Deployments utilizing reverse proxies (such as Nginx, HAProxy, or Cloudflare) require specific configuration to ensure the rate limiter functions correctly. Administrators must populate the trustedProxies variable within the OpenClaw gateway settings.

If the proxy configuration is omitted, resolveWebhookClientIp will record the internal IP address of the reverse proxy instead of the external client. This misconfiguration causes the rate limiter to enforce a global limit across all inbound traffic, potentially resulting in a self-inflicted denial-of-service condition for legitimate webhook events.