GHSA-qcc3-jqwp-5vh2: Unauthenticated Resource Exhaustion via LINE Webhook Handler in OpenClaw

The openclaw npm package provides the core functionality for the OpenClaw personal AI assistant. A critical component of this ecosystem is the LINE messaging integration, which relies on a webhook endpoint (/line/webhook) to receive event notifications from the LINE platform.

This webhook implementation suffers from an Uncontrolled Resource Consumption vulnerability, classified under CWE-400 and CWE-770. The application receives incoming POST requests and immediately begins heavy processing tasks without applying any rate limits or concurrency constraints at the application layer.

The flaw exists because cryptographic signature verification and request body parsing occur before the system validates the legitimacy of the sender. An unauthenticated attacker can exploit this architectural design by opening multiple concurrent connections, forcing the Node.js event loop to dedicate all available resources to processing malicious requests.

The resulting system state is a complete Denial of Service (DoS). Legitimate webhook events are dropped, and other services sharing the same Node.js process become completely unresponsive due to event loop starvation and memory pressure.

The core technical failure resides in the request lifecycle of the /line/webhook endpoint. When a POST request arrives, the server allocates memory to read the full HTTP request body. Following this allocation, the system uses the channelSecret to calculate an HMAC-SHA256 signature to verify the payload against the provided header.

Both memory allocation for arbitrary payload sizes and cryptographic hashing are synchronous or heavy asynchronous operations. They consume measurable CPU cycles and heap memory per request. The vulnerability is triggered because these operations execute on every incoming connection regardless of the current system load or the origin of the request.

The lack of an "in-flight" concurrency limiter prior to authentication allows an attacker to dictate the resource allocation of the server. By issuing thousands of simultaneous POST requests, the attacker forces the Node.js server to allocate memory and queue cryptographic operations concurrently.

Because Node.js operates on a single-threaded event loop, queueing a massive number of cryptographic operations prevents the loop from servicing legitimate I/O tasks. The server accepts all connections simultaneously, rapidly exhausting available memory and CPU cycles before any single request reaches the signature invalidation phase.

In vulnerable versions, the OpenClaw router unconditionally invoked the scope handler for every POST request directed to the webhook path. There was no mechanism to track how many requests were actively being processed for a given account.

The patch introduced in commit 57c47d8c7fbf5a2e70cc4dec2380977968903cad fundamentally changes this behavior by implementing a shared concurrency budget. The developers introduced createWebhookInFlightLimiter, a utility designed to track active requests, and implemented beginWebhookRequestPipelineOrReject as a pre-authentication guard.

handler: async (req, res) => {
  if (req.method !== "POST") {
    await createScopedLineWebhookHandler()(req, res);
    return;
  }
 
  // NEW: Concurrency guard before any heavy lifting
  const requestLifecycle = beginWebhookRequestPipelineOrReject({
    req,
    res,
    inFlightLimiter: lineWebhookInFlightLimiter,
    inFlightKey: `line:${resolvedAccountId}`,
  });
  
  if (!requestLifecycle.ok) {
    return; // Request already ended with 429
  }
 
  try {
    // Only proceeds to read body and verify signature if under budget
    await createScopedLineWebhookHandler(requestLifecycle.release)(req, res);
  } finally {
    requestLifecycle.release();
  }
}

This patched implementation successfully mitigates the vulnerability by keying the concurrency limit to the specific resolvedAccountId. If the active request count exceeds the defined maxInFlightPerKey threshold, the server immediately returns an HTTP 429 (Too Many Requests) response.

By rejecting the request synchronously before allocating memory for the body or invoking HMAC operations, the server preserves its operational state. The fix is considered comprehensive as it addresses the exact location of the resource drain.

Exploitation of this vulnerability requires only network routing to the OpenClaw API endpoint. The attacker does not need valid credentials, an active account, or a valid LINE cryptographic signature. The exploit utilizes high-concurrency connection flooding to overwhelm the target.

An attacker executes the attack using standard HTTP benchmarking tools like h2load or ab, or via custom scripts configured to maximize concurrent connections. The tool targets the default /line/webhook endpoint with POST requests containing arbitrarily large bodies and fake signature headers.

The server attempts to process all connections simultaneously. Because the rejection logic only executes after the expensive body reading and hashing functions complete, the concurrent connections stack up in the event loop queue.

During an active exploit, administrators will observe the Node.js process CPU utilization spike to 100%. Memory consumption will climb linearly with the number of concurrent connections until the V8 engine garbage collector fails to keep up, often resulting in an Out-Of-Memory (OOM) crash.

The primary impact of this vulnerability is a complete loss of availability. The resource exhaustion prevents the personal AI assistant from responding to legitimate user inputs, scheduled tasks, and valid incoming LINE messages. The service effectively goes offline during the attack.

Secondary systemic impacts occur at the host level. The unhandled resource consumption routinely triggers Out-Of-Memory killer mechanisms or CPU throttling on the host operating system. This can degrade the performance of other containers or applications sharing the same physical or virtual hardware.

The vulnerability is assessed with a CVSS v3.1 vector of CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L yielding a score of 5.3. While the maintainers categorized the ecosystem impact as "Low," the reliability of the exploit means any exposed, unpatched OpenClaw instance is highly susceptible to trivial disruption.

There is no impact on confidentiality or integrity. The attacker cannot extract data, bypass authentication, or modify the system state beyond consuming available resources.

The primary and most effective remediation is to update the openclaw npm package to version 2026.3.31 or later. This release contains the shared concurrency budget architecture necessary to protect the endpoint from connection floods.

For systems that cannot be immediately patched, network-level mitigations must be implemented. Operators should configure a reverse proxy (such as NGINX or HAProxy) or a Web Application Firewall (WAF) to strictly rate-limit POST requests directed at the /line/webhook URI.

Administrators operating patched versions in high-traffic environments should review the WEBHOOK_IN_FLIGHT_DEFAULTS thresholds. Ensure these values accommodate the expected peak volume of legitimate LINE events to prevent false positive rate-limiting under normal operational loads.

Security monitoring should be updated to track HTTP 429 status codes originating from the webhook endpoint. A sudden, sustained spike in 429 responses is a strong indicator of either an active denial-of-service attempt or a misconfiguration in the upstream LINE integration logic.