GHSA-V865-P3GQ-HW6M: Path Canonicalization Bypass in OpenClaw Gateway

The OpenClaw AI infrastructure utilizes a centralized gateway acting as a Policy Enforcement Point (PEP). This component is responsible for intercepting incoming HTTP requests and enforcing authentication on protected routes, specifically those prefixed with /api/channels. The security model relies on comparing the incoming request path against a list of known protected prefixes.

However, the mechanism for normalizing these paths prior to inspection was insufficient. The gateway employed a shallow decoding strategy with a fixed limit on decoding passes. This created a discrepancy between how the security layer viewed the request path and how the internal plugin router interpreted it—a vulnerability class known as "Path Impedance Mismatch" (CWE-436).

Consequently, attackers can craft HTTP requests with multi-encoded characters (such as %25252f for /) that evade the gateway's blocklist but successfully resolve to sensitive endpoints within the application's routing logic. This effectively bypasses authentication for affected plugins.

The vulnerability arises from two distinct architectural flaws: bounded shallow canonicalization and implicit route registration.

First, the gateway's canonicalizePathForSecurity function enforced a hard limit of 3 decoding passes (MAX_PATH_DECODE_PASSES = 3). The intent was likely to prevent Denial of Service (DoS) via infinite decoding loops. However, this limit was too low. If an attacker encoded a slash character four times (e.g., %2525252f), the gateway would decode it three times, resulting in a string containing %2f. Since %2f is not a literal slash /, the prefix check path.startsWith("/api/channels") would fail, and the gateway would forward the request as "public" traffic.

Second, the plugin architecture utilized a generic api.registerHttpHandler() method. This method registered broad catch-all handlers without explicit authentication metadata. The internal router, typically using a robust framework-level decoder, would continue decoding the path until resolution, eventually interpreting the lingering %2f as a valid directory separator. This alignment failure allowed the request to reach the handler code, which assumed authentication had already been performed by the gateway.

The remediation strategy involved shifting from a shallow decode to a bounded fixpoint strategy with fail-closed logic. Below is a conceptual representation of the vulnerability and the fix.

Vulnerable Logic (Simplified)

// Pre-fix: Limited passes allowed evasion
const MAX_PATH_DECODE_PASSES = 3;
 
function canonicalizePathForSecurity(path) {
  let decoded = path;
  for (let i = 0; i < MAX_PATH_DECODE_PASSES; i++) {
    const next = decodeURIComponent(decoded);
    if (next === decoded) break;
    decoded = next;
  }
  // If attacker used 4x encoding, 'decoded' still contains encoded chars
  // and might not match the protected prefix.
  return decoded;
}

Patched Logic

// Post-fix: Deep decode with anomaly detection
const MAX_PATH_DECODE_PASSES = 32;
 
function canonicalizePathForSecurity(path) {
  let decoded = path;
  let i = 0;
  
  while (i < MAX_PATH_DECODE_PASSES) {
    const next = decodeURIComponent(decoded);
    if (next === decoded) return decoded; // Stable
    decoded = next;
    i++;
  }
 
  // FIX: If we hit the limit, assume malicious intent (Fail-Closed)
  throw new SecurityAnomaly("Path canonicalization depth exceeded");
}
 
// Additional check: If result still looks encoded, treat as suspicious
if (decoded.includes("%")) {
    requireFullAuthentication();
}

The fix increases the decode limit significantly and, crucially, treats the exhaustion of this limit or the presence of residual encoded artifacts as a security anomaly, forcing a default-deny or full-auth state.

To exploit this vulnerability, an attacker targets a specific endpoint known to require authentication, such as the configuration profile for a messaging channel.

Target: /api/channels/nostr/default/profile

Attack Vector:

1. The attacker constructs a request where the slashes are triple-encoded: /api%25252fchannels%25252fnostr.
2. The OpenClaw gateway receives the request. Its decoder runs 3 times, stripping layers of encoding but stopping while the string still contains %2f (encoded slash).
3. The gateway checks if the path starts with /api/channels. It does not, because the string is literally /api%2fchannels.
4. The gateway classifies the request as public/unrestricted and forwards it.
5. The internal router receives /api%2fchannels... and decodes it fully to /api/channels/nostr.
6. The router matches this to the sensitive handler, which executes without checking for a session token.

This grants the attacker read/write access to the channel configuration depending on the HTTP method used.

This vulnerability represents a significant security lapse for deployments exposing the OpenClaw gateway to untrusted networks. The primary impact is Authentication Bypass, allowing unauthorized interaction with internal plugins.

Confidentiality: Attackers can access private channel data, chat history (via plugins like BlueBubbles or Zalo), and system configuration profiles.

Integrity: If the protected endpoints support state-changing operations (POST/PUT/DELETE), an attacker could modify channel settings, inject malicious configuration, or disrupt service operations.

Availability: While primarily an access control issue, the "Service Shadowing" effect mentioned in the advisory could allow malicious plugins to hijack routes intended for legitimate services, leading to denial of service for specific features.