CVE-2026-100572 in OpenClaw
Summary
by MITRE • 09/26/2026
OpenClaw versions >= 2026.3.25 and < 2026.8.1 apply invalid-token rate limiting for Synology Chat webhooks before authentication and key the limit on the raw proxy socket address. In deployments where OpenClaw sits behind a trusted reverse proxy or tunnel and multiple external clients share a single socket address, an unauthenticated sender can exhaust the shared invalid-token budget, causing subsequent legitimate Synology Chat webhook callbacks to be rejected until the rate-limit window expires. The attacker cannot obtain a valid token or read message data; the impact is temporary loss of channel availability. Fixed in 2026.8.1.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 09/26/2026
The vulnerability identified in OpenClaw versions ranging from 2026.3.25 up to, but not including, version 2026.8.1 represents a significant flaw in the application's access control and rate limiting mechanisms for Synology Chat webhooks. The core technical deficiency lies in the sequence of operations performed during request processing. Specifically, OpenClaw applies invalid-token rate limiting before performing authentication checks on incoming webhook requests. This architectural decision means that any request lacking valid credentials is immediately subjected to a counter associated with its source network address rather than being rejected outright without penalty or processed through an unauthenticated queue that does not consume resources in the same manner. Furthermore, this rate limit bucket is keyed exclusively on the raw proxy socket address of the incoming connection. This design choice fails to account for modern deployment architectures where OpenClaw operates behind trusted reverse proxies, load balancers, or tunneling services.
In environments utilizing a shared infrastructure model, multiple external clients often route their traffic through a single entry point, resulting in all requests appearing to originate from one specific IP address at the application layer. Because the rate limiting logic relies on this raw socket address as the unique identifier for tracking invalid attempts, it aggregates the failure counts of all distinct users sharing that connection path into a single pool. Consequently, an unauthenticated attacker can deliberately send malformed or unauthorized webhook requests to exhaust the shared budget allocated for invalid tokens. This action does not require any form of authentication bypass nor does it allow the attacker to read sensitive message data or obtain valid session tokens. The impact is strictly confined to availability, as the exhaustion of this rate limit causes OpenClaw to reject all subsequent legitimate Synology Chat webhook callbacks from other users sharing the same proxy address until the configured time window expires.
This scenario aligns with Common Weakness Enumeration (CWE) category CWE-770: Allocation of Resources Without Limits or Throttling, specifically regarding resource exhaustion through improper rate limiting boundaries. Additionally, it reflects aspects of ATT&CK technique T1498: Network Denial of Service, as the attacker leverages a misconfiguration in access control logic to degrade service availability for legitimate users. The vulnerability highlights the critical importance of distinguishing between client identity and network topology when implementing security controls such as rate limiting. By binding limits to IP addresses rather than user identities or application-level session tokens, the system becomes vulnerable to collateral damage attacks where one malicious actor can disrupt services for unrelated parties sharing the same egress point.
To mitigate this vulnerability, organizations must upgrade OpenClaw to version 2026.8.1 or later, which resolves the issue by correcting the rate limiting logic and its keying mechanism. In interim scenarios where an immediate patch is not feasible, administrators should consider implementing network-level segmentation to ensure that untrusted external clients do not share socket addresses with legitimate webhook sources if possible. Additionally, configuring reverse proxies to pass unique client identifiers via headers such as X-Forwarded-For or custom application-specific tokens can allow the backend service to distinguish between different users even when they traverse a shared proxy infrastructure. However, these workarounds are less robust than applying the vendor-provided fix which addresses the root cause by ensuring that rate limits are applied after authentication checks and keyed on user identity rather than raw network address.