OpenClaw CVE-2026-41362

Valid authenticated access to at least one Zalo webhook path in the OpenClaw deployment is required (PR:L satisfaction). The OpenClaw instance must be configured in multi-account or multi-tenant mode where multiple authenticated webhook targets share the same underlying replay-deduplication cache storage. Default single-tenant or isolated webhook configurations are not vulnerable. The attacker must know or infer the event_name and message_id values of target events (this information may be guessable for common webhook event types or obtainable through prior reconnaissance). Exploitation requires timing the crafted webhook event to arrive before or concurrent with the legitimate event to prevent cache expiration, introducing the AT:P (prior timing required) factor. Systems with isolated per-tenant cache backends or cache namespacing by account ID are not vulnerable.

The CVSS 2.3 score with CVSS:4.0/AV:N/AC:L/AT:P/PR:L indicates low severity: network-accessible, low complexity, but requires prior authentication (PR:L) and periodic timing (AT:P). The impact vector shows integrity impact only (VI:L), not confidentiality or availability at base metrics, though the functional impact is event suppression (denial of service to webhook processing). The AT:P (prior timing required) modifier significantly reduces exploitability-the attacker must send crafted webhook events with matching parameters at precise times relative to legitimate events on victim accounts. EPSS score unavailable, but indicators suggest this is a low-probability real-world risk: authentication requirement acts as a gate, AT:P timing dependency requires coordination with victim webhook activity, and the impact is lateral suppression within a multi-account system rather than data breach or full system compromise. This is not a zero-day or widespread threat. Organizations with single-tenant or isolated webhook deployments face minimal risk. Multi-tenant deployments where different customers' webhooks share infrastructure are at higher risk, particularly if webhook suppression directly impacts business logic (e.g., payment confirmations, order notifications). No KEV confirmation or public exploit identified. Confidence is moderate due to lack of EPSS and limited disclosure details.

An attacker with a valid authenticated Zalo webhook path on Account A observes the event_name and message_id values of legitimate webhook events destined for Account B (either through reconnaissance or guessing common patterns like 'order.created' with sequential message IDs). The attacker sends a crafted webhook event with matching event_name and message_id to their own Account A webhook path, causing the shared replay-dedupe cache to record the event as processed. When the legitimate event subsequently arrives for Account B's webhook handler, the cache prevents reprocessing, and Account B never receives the critical event (e.g., payment confirmation), disrupting their business process.