GHSA-3m3q-x3gj-f79x
MEDIUMOpenClaw optional voice-call plugin: webhook verification may be bypassed behind certain proxy configurations
EPSS Exploitation Probability
EPSS (Exploit Prediction Scoring System) is a daily probability model maintained by FIRST.org. It estimates the likelihood a CVE will be exploited in production environments within the next 30 days, derived from real-world threat intelligence signals.
Blast Radius
@openclaw/voice-call📦@clawdbot/voice-callReal-time download stats are indexed for npm and PyPI packages. This vulnerability affects npm packages — download data is not available via public APIs for these ecosystems.
Description
Affected Packages / Versions
This issue affects the optional voice-call plugin only. It is not enabled by default; it only applies to installations where the plugin is installed and enabled.
- Package:
@openclaw/voice-call - Vulnerable versions:
< 2026.2.3 - Patched versions:
>= 2026.2.3
Legacy package name (if you are still using it):
- Package:
@clawdbot/voice-call - Vulnerable versions:
<= 2026.1.24 - Patched versions: none published under this package name; migrate to
@openclaw/voice-call
Summary
In certain reverse-proxy / forwarding setups, webhook verification can be bypassed if untrusted forwarded headers are accepted.
Impact
An external party may be able to send voice-call webhook requests that are accepted as valid, which can result in spoofed webhook events being processed.
Root Cause
Some deployments implicitly trusted forwarded headers (for example Forwarded / X-Forwarded-*) when determining request properties used during webhook verification. If those headers are not overwritten by a trusted proxy, a client can supply them directly and influence verification.
Resolution
Ignore forwarded headers by default unless explicitly trusted and allowlisted in configuration. Keep any loopback-only development bypass restricted to local development only. Upgrade to a patched version.
If you cannot upgrade immediately, strip Forwarded and X-Forwarded-* headers at the edge so clients cannot supply them directly.
Fix Commit(s)
a749db9820eb6d6224032a5a34223d286d2dcc2f
Credits
Thanks @0x5t for reporting.
Affected Packages
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| 📦npm | @openclaw/voice-call | all versions | 2026.2.3 |
| 📦npm | @clawdbot/voice-call | all versions | No fix |
Detection & mitigation playbook
Open-source dependencyDetect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for @openclaw/voice-call. O3's reachability analysis confirms whether the vulnerable code path is actually invoked in your application, so you act on real exposure instead of every transitive match.
Fix
Update @openclaw/voice-call to 2026.2.3 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-3m3q-x3gj-f79x is resolved across your whole dependency graph.
Workarounds
If you can't upgrade right away: gate or disable the affected feature, validate untrusted input at the boundary, and avoid passing attacker-controlled data into the vulnerable path. O3's runtime protection blocks exploitation in production as an interim safeguard until the upgrade lands.
How O3 protects you
O3 pinpoints whether GHSA-3m3q-x3gj-f79x is reachable in your code and exactly where to fix it, then blocks exploitation in production at runtime until the patched version is deployed.
Tailored to GHSA-3m3q-x3gj-f79x. Runtime protection reduces exposure until a permanent patch is applied and verified — it complements patching, it doesn't replace it.
Frequently Asked Questions
Is GHSA-3m3q-x3gj-f79x in your dependencies?
O3 detects GHSA-3m3q-x3gj-f79x across npm dependencies and uses function-level reachability to confirm whether the vulnerable code path is actually reachable — not just present. No false positives.