GHSA-JMM5-FVH5-GF4P: Timing Side-Channel in OpenClaw Authentication

The OpenClaw AI assistant platform exposes endpoints for webhooks and device pairing that are protected by shared secret tokens. In versions prior to 2026.2.12, the authentication logic for these endpoints relies on insecure string comparison operations. This flaw introduces a timing side-channel that correlates the server's response time with the correctness of the provided token.

Timing side-channels occur when an algorithm's execution time depends on secret data. In this specific instance, the vulnerability allows an unauthenticated attacker to discern how many characters of their guessed token match the actual server-side secret. By iteratively guessing characters and statistically analyzing the response latency, an attacker can reconstruct the full authentication token, bypassing security controls entirely.

The vulnerability stems from the use of the standard JavaScript inequality operator (!==) to compare the incoming request token against the configured secret. The affected logic was primarily located in src/gateway/server-http.ts and src/infra/device-pairing.ts.

Modern JavaScript engines, such as V8, optimize string comparison using a byte-by-byte approach that returns false immediately upon encountering a mismatch. This optimization creates a linear relationship between the time taken to compare two strings and the length of their common prefix. If the first character matches, the engine checks the second; if that matches, it checks the third, and so on.

Consequently, a guess that matches the first N characters of the secret will take slightly longer to process than a guess that matches only N-1 characters. Although this time difference is often measured in nanoseconds or microseconds, it aggregates to a measurable signal over a network, particularly in low-latency environments or when averaging thousands of requests to filter out network jitter.

The following analysis contrasts the vulnerable implementation with the patched version introduced in commit 113ebfd6a23c4beb8a575d48f7482593254506ec.

Vulnerable Implementation In src/gateway/server-http.ts, the code performed a direct comparison. This operation is not constant-time.

// src/gateway/server-http.ts
const token = extractHookToken(req);
 
// VULNERABLE: The !== operator exits early on mismatch
if (!token || token !== hooksConfig.token) {
  res.statusCode = 401;
  // ... return error
}

Patched Implementation The fix introduces a dedicated security utility safeEqualSecret in src/security/secret-equal.ts. This utility leverages Node.js's crypto module to perform a constant-time comparison.

// src/security/secret-equal.ts
import { timingSafeEqual } from "node:crypto";
 
export function safeEqualSecret(
  provided: string | undefined | null,
  expected: string | undefined | null,
): boolean {
  // ... type checks ...
  
  const providedBuffer = Buffer.from(provided);
  const expectedBuffer = Buffer.from(expected);
 
  // NOTE: This check still leaks the length of the secret via timing
  if (providedBuffer.length !== expectedBuffer.length) {
    return false; 
  }
 
  // FIXED: Constant-time comparison prevents content leakage
  return timingSafeEqual(providedBuffer, expectedBuffer);
}

> [!NOTE] > While crypto.timingSafeEqual prevents the leakage of the content of the secret, the explicit length check (!==) still leaks the length of the secret. An attacker can determine the token length before attempting to guess its content.

To exploit this vulnerability, an attacker acts as an oracle, submitting candidate tokens and measuring the time to receive the 401 Unauthorized response. The attack proceeds in two phases:

1. Length Discovery: The attacker sends tokens of varying lengths. The length that results in a significantly different response time (typically slightly longer due to the allocation or the subsequent comparison logic) reveals the length of the valid token.
2. Content Extraction: The attacker iterates through the character set for the first byte of the token. They send hundreds or thousands of requests for each candidate character. Statistical analysis (e.g., box plots or mean deviation) is applied to identify the candidate that consistently yields the highest latency. This character is fixed, and the process repeats for the next byte.

This attack vector allows for the recovery of API keys, webhook secrets, and device pairing tokens without any prior credentials.

The vulnerability was addressed in OpenClaw version 2026.2.12. The remediation strategy involved two key changes:

1. Constant-Time Comparison: Replacing strict equality operators with crypto.timingSafeEqual ensures that the comparison time remains independent of the input's correctness, provided the lengths match.
2. Rate Limiting: A throttle was implemented to limit clients to 20 failed authentication attempts per 60-second window. This dramatically increases the time required to collect enough samples to overcome network jitter.

Residual Risks Despite the patch, technical analysis reveals two lingering concerns:

1. Length Leakage: The fix explicitly checks buffer lengths before the constant-time comparison. While less critical than content leakage, this still allows attackers to determine the exact size of the secret.
2. Rate Limiter State Exhaustion: The hookAuthFailures map, used to track failed attempts, clears entirely when it reaches 2048 entries. A sophisticated attacker could flood the server with requests from spoofed IPs to fill this map, forcing a reset of the rate limit counters and effectively bypassing the throttling mechanism.