GHSA-gfg9-5357-hv4c
OpenClaw: Webchat audio embedding could read local files without local-root containment
Blast Radius
Weekly download volume for affected packages — a proxy for how broadly this vulnerability is deployed.
openclawnpmDescription
Impact
OpenClaw deployments before 2026.4.15 could embed host-local audio files into webchat responses without applying the local media root containment check used by other media-serving paths.
If an attacker could influence an agent or tool-produced ReplyPayload.mediaUrl, the webchat audio embedding helper could resolve an absolute local path or file: URL, read an audio-like file under the size cap, and base64-encode it into the webchat media response. This crossed the model/tool-output boundary into a host file read. Prompt injection or malicious tool output is a delivery mechanism; the security boundary failure is the missing local-root containment check.
The impact is narrow: the file had to be readable by the gateway process, have an audio-like extension, and fit within the webchat audio size cap. The issue exposed contents into the webchat assistant/media transcript path; it was not a general remote filesystem API.
Affected Packages / Versions
- Package:
openclawon npm - Affected versions:
<= 2026.4.14 - Patched version:
2026.4.15
The latest public release, 2026.4.21, also contains the fix.
Patches
The public fix threads the applicable local media roots into the webchat audio embedding path and calls assertLocalMediaAllowed before local audio content is read. Current main also includes an additional trustedLocalMedia gate so untrusted model/tool payloads cannot opt into local audio embedding.
Fix commit:
6e58f1f9f54bca1fea1268ec0ee4c01a2af03dde
Workarounds
Upgrade to [email protected] or later. The latest public release, 2026.4.21, is fixed. Before upgrading, avoid exposing webchat sessions to untrusted prompt/tool content that can influence reply media URLs.
Credits
OpenClaw thanks @zsxsoft for reporting.
Affected Packages
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| 📦npm | openclaw | all versions | 2026.4.15 |
Detection & mitigation playbook
Open-source dependencyDetect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for openclaw. 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 to 2026.4.15 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-gfg9-5357-hv4c 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-gfg9-5357-hv4c 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-gfg9-5357-hv4c. 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-gfg9-5357-hv4c in your dependencies?
O3 detects GHSA-gfg9-5357-hv4c across npm dependencies and uses function-level reachability to confirm whether the vulnerable code path is actually reachable — not just present. No false positives.