OpenClaw CVE-2026-100571

Requires the OpenClaw SMS/Twilio webhook to be deployed behind a trusted reverse proxy or tunnel such that multiple external clients are collapsed to a single raw proxy socket address (the client identifier used for the pre-signature invalid-request rate limit). In a direct/single-client deployment where clients present distinct socket addresses, the shared-budget exhaustion does not occur. No authentication is needed (PR:N) and no user interaction is required, but exploitation is limited to denial of inbound SMS during the exhausted window - the attacker cannot forge a signed Twilio callback or read any message data, and service self-recovers when the rate-limit window resets.

This is a low-impact availability issue whose CVSS reflects that honestly. The vendor CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:L) scores 6.9 but is explicitly confidentiality/integrity-free (VC:N/VI:N) with only Low availability impact (VA:L) - the 6.9 is inflated by CVSS 4.0's network/unauth weighting relative to the real-world consequence, which the description bounds tightly to 'temporary inbound SMS loss' with no data access and no callback forgery. There is no EPSS score, no CISA KEV listing, and no public exploit code identified at time of analysis, so exploitation status is 'no public exploit identified at time of analysis.' Crucially, the flaw is not present in default single-client deployments: it only manifests 'in deployments where the SMS/Twilio webhook sits behind a trusted reverse proxy or tunnel so that multiple external clients share one socket address' - a specific, self-limiting configuration. Net assessment: real but minor. This is a high-CVSS-but-low-real-risk item - a transient, self-healing DoS on an optional SMS integration of a niche open-source agent framework, not an urgent priority.

An OpenClaw operator runs the Twilio SMS webhook behind a shared reverse proxy or tunnel, so all inbound requests present the same socket address. An unauthenticated remote attacker floods the endpoint with invalid (unsigned) requests, exhausting the shared pre-authentication invalid-request rate-limit budget before signature verification runs. Legitimate, correctly-signed Twilio callbacks then receive HTTP 429 and are dropped, silencing inbound SMS until the shared window resets. No public exploit code is known.