OpenClaw: Webchat audio embedding could read local files without local-root containment

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: openclaw on 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 openclaw@2026.4.15 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.