OpenClaw voice-call CVE-2026-28465

Exploitation requires the OPTIONAL @openclaw/voice-call plugin to be installed and enabled (it is not enabled by default), AND a deployment where a reverse proxy or tunnel (e.g. ngrok) sits in front of the Gateway and does NOT overwrite or strip client-supplied Forwarded / X-Forwarded-* headers before they reach the plugin. In such setups the plugin implicitly trusts these forwarding headers to reconstruct the public URL used for webhook signature verification, letting a remote unauthenticated client set them directly. Limiting factors: high attack complexity and an attack requirement (AC:H/AT:P) tied to the specific proxy misconfiguration; impact is integrity-only (spoofed webhook events), with no confidentiality or availability effect; default configs that strip these headers at the edge, or the patched version's allowedHosts/trustedProxyIPs allowlist, are not exploitable.

Signals point to a real but conditional integrity issue rather than a broadly weaponizable flaw. The vendor CVSS 4.0 vector (8.2) is driven by VI:H (spoofed/forged webhook events accepted as valid) but explicitly scopes confidentiality and availability to none (VC:N/VA:N) and requires both high attack complexity (AC:H) and a specific attack requirement (AT:P) - meaning exploitation only works against particular reverse-proxy/tunnel deployments that implicitly trust forwarded headers. My independent CVSS 3.1 mapping lands at ~5.9 (Medium), notably lower than the headline 8.2, because 3.1 lacks the 4.0 nuance and the impact is integrity-only. EPSS is low at 0.12% (32th percentile), consistent with a non-default, configuration-dependent bug. There is no CISA KEV listing and no public exploit code referenced, so this is not confirmed active exploitation. Net: a legitimate authentication-bypass (CWE-290) worth patching for anyone running the optional voice-call plugin behind a proxy, but it is a targeted, deployment-specific issue - not a high-urgency internet-wide threat. The main data tension to note: the 4.0 base score (8.2/High) overstates real-world urgency relative to EPSS, the integrity-only impact, and the AC:H/AT:P gating.

An attacker who can reach the voice-call webhook endpoint directly (behind a reverse proxy or tunnel that does not strip client-supplied forwarding headers) sends a crafted request setting Forwarded or X-Forwarded-* headers to a value the plugin implicitly trusts during webhook URL/signature reconstruction. The plugin accepts the forged host context and treats the spoofed voice-call webhook event as verified, causing the application to process attacker-controlled events. No public exploit code is identified at time of analysis, though the root cause and fix are documented in the GHSA advisory and commit diff.