Openclaw EUVD-2026-21458

This vulnerability presents a moderate but practically exploitable risk. The CVSS vector (AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:N) indicates network attack vector with low complexity and no authentication required, making exploitation straightforward. The 6.5 base score reflects partial confidentiality and integrity impact without availability disruption. The real-world risk is elevated because: (1) the attack requires no authentication or user interaction, (2) the attack complexity is low-simply crafting HTTP headers-and (3) the attack bypasses two security controls simultaneously (authentication and rate-limiting), which are often the primary defenses against abuse. However, the vulnerability has containment factors: it only affects deployments explicitly configured with trustedProxies settings (not default configurations), and the impact is limited to information disclosure and integrity compromise rather than remote code execution or complete system compromise. The lack of availability impact (no DoS) further moderates severity. Given that patch availability is confirmed and the vulnerability is not listed as actively exploited (no KEV status in input), this should be treated as a moderate-priority patch for affected deployments, with urgency highest for public-facing instances with proxy configurations.

An attacker targeting a public-facing OpenClaw instance with trustedProxies configured observes or infers the legitimate proxy IP addresses. The attacker crafts HTTP requests with custom X-Forwarded-For headers containing loopback addresses (127.0.0.1) placed behind the trusted proxy IP, causing the application to believe the request originated from a local service. By exploiting this spoofed loopback status, the attacker bypasses rate-limiting restrictions that typically exempt local connections and forges or manipulates canvas authentication tokens. This allows the attacker to perform repeated requests without rate-limit penalties or to gain unauthorized access to canvas functionality that should be restricted to authenticated users. No public exploit code or active exploitation has been confirmed at the time of analysis, but the straightforward nature of HTTP header injection makes practical exploitation trivial.