GHSA-RM59-992W-X2MV: Unauthenticated Resource Exhaustion and DoS in OpenClaw Voice Webhooks

OpenClaw exposes webhook endpoints designed to integrate with external voice providers such as Twilio, Telnyx, and Plivo. These ingress points asynchronously process event notifications over HTTP to facilitate the application's core communication features. Prior to version 2026.3.23, the webhook handling logic failed to enforce adequate resource constraints during the pre-authentication phase of request processing.

This lack of constraints exposed the application to unauthenticated resource exhaustion, categorized under CWE-400 (Uncontrolled Resource Consumption). Unauthenticated actors could interact with these public-facing endpoints and consume disproportionate server resources by initiating HTTP requests that deliberately delayed or maximized body payload transmission.

The vulnerability permitted a remote attacker to saturate the server's connection pool, deplete available memory, and exhaust worker threads. Consequently, legitimate webhook events from actual providers were dropped, rendering the voice communication subsystem and the broader OpenClaw application entirely unresponsive.

The underlying vulnerability stems from a defective "buffer-then-verify" architectural pattern implemented within extensions/voice-call/src/webhook.ts. When handling inbound HTTP requests from voice providers, the server unconditionally allocated memory to read the incoming request body before verifying the authenticity of the sender.

Specifically, the original implementation permitted the server to buffer up to 1 MB of payload data into memory per connection. Furthermore, the application enforced a highly permissive 30-second timeout for the client to complete the body transmission. Cryptographic signature verification, the primary authentication mechanism for webhook providers, was executed strictly after the 1 MB payload had been fully transferred and buffered.

This operational sequence improperly committed expensive server resources—memory, socket file descriptors, and application worker threads—to untrusted network connections. An attacker could thereby leverage the pre-authentication phase to stockpile dormant connections, directly starving the application of the resources required to process legitimate traffic.

The pre-patch implementation consumed the HTTP stream blindly, invoking the verification routine only upon stream conclusion. Commit 651dc7450b68a5396a009db78ef9382633707ead restructures this ingress pipeline by implementing a strict multi-layered defense mechanism before payload extraction begins.

The patch introduces a header gate that proactively inspects the incoming request for provider-specific signature headers, such as x-twilio-signature, telnyx-signature-ed25519, or x-plivo-signature-v3. If these headers are absent, the connection is immediately terminated with an HTTP 401 status code, bypassing the buffering phase entirely.

For requests containing the requisite headers, the patch reduces the maximum permitted body size from 1 MB to 64 KB, and constrains the transmission timeout from 30 seconds to 5 seconds. Additionally, the patch introduces a concurrency limiter (webhookInFlightLimiter) that tracks active pre-authentication requests by source IP address. If an IP exceeds 8 concurrent requests, the server returns an HTTP 429 status code.

Exploitation requires the attacker to target the exposed OpenClaw voice webhook endpoint, typically located at paths similar to /webhooks/voice/twilio. The attacker initializes multiple concurrent TCP connections to the target service without providing valid authentication credentials.

To maximize resource consumption, the attacker transmits HTTP POST requests equipped with dummy provider signature headers to bypass initial naive checks, if any exist. The attacker then transmits the payload at an intentionally degraded rate—analogous to a Slowloris attack—or submits maximum-sized payloads up to the 1 MB limit. This forces the server to hold the connections open for the full 30-second timeout.

By rotating source IP addresses or leveraging a distributed botnet, the attacker continuously replenishes these stalled connections. The server rapidly exhausts its maximum concurrent connection limits and available memory pool. The application enters a Denial of Service state, failing to service benign requests across all system components sharing the underlying web server infrastructure.

Successful exploitation of this vulnerability results in a total Denial of Service (DoS) for the affected OpenClaw instance. The application becomes incapable of processing legitimate voice call webhooks or any other network requests handled by the saturated worker pool.

The vulnerability requires zero authentication and possesses a low attack complexity (CVSS v3.1 Vector: AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H). It is highly exploitable via standard, automated denial-of-service toolkits or simple single-source scripts. A single malicious actor with limited bandwidth can effectively disable the service by maximizing the concurrent connection limits via slow-read or slow-post techniques.

While this specific vulnerability does not permit remote code execution, arbitrary file reading, or data exfiltration, the loss of availability directly degrades the core functionality of the AI assistant. Services relying on real-time webhook ingestion will experience total failure during the attack window.

Administrators must upgrade OpenClaw to version 2026.3.23 or later. This release contains the complete structural patch for the webhook ingress pipeline, implementing the required header gates, strict budget reductions, and IP-based concurrency limiters.

Organizations unable to immediately apply the software patch should deploy a reverse proxy or Web Application Firewall (WAF) in front of the OpenClaw instance. The WAF must be configured to inspect traffic targeting the voice webhook endpoints and drop any requests lacking the specific provider signature headers (e.g., x-twilio-signature, telnyx-signature-ed25519, x-plivo-signature-v3).

Furthermore, applying strict rate limiting per source IP at the ingress controller or load balancer level will substantially mitigate the efficacy of connection exhaustion attacks. Network administrators should monitor inbound connections to the webhook endpoints and alert on unusually high connection duration times or payload sizes.