In approval-enabled host=node workflows, system.run approvals did not always carry a strict, versioned execution-context binding. In uncommon setups that rely on these approvals as an integrity guardrail, a previously approved request could be reused with changed env input.
openclaw2026.2.25<= 2026.2.252026.2.26This requires all of the following:
- system.run usage through host=node
- Exec approvals enabled and used as an execution-integrity control
- Access to an approval id in the same context
Most default single-operator local setups do not rely on this path, so practical exposure is typically lower.
Approval matching now uses a required versioned binding (systemRunBindingV1) over command argv, cwd, agent/session context, and env hash.
The fix:
- Requires commandArgv when requesting host=node approvals.
- Requires systemRunBindingV1 when consuming approvals for node system.run.
- Removes legacy non-versioned fallback matching and fails closed on missing/mismatched bindings.
- Keeps env mismatch handling explicit and blocks GIT_EXTERNAL_DIFF in host env policy.
- Adds/updates regression and contract coverage for mismatch mapping and binding rules.
Configuration-dependent approval-integrity weakness in node-host exec approval flows. Severity remains medium because exploitation depends on this specific approval mode and context.
10481097f8e6dd0346db9be0b5f27570e1bdfcfapatched_versions is pre-set to the planned next release (2026.2.26) so once npm release 2026.2.26 is published, the advisory can be published without further metadata edits.
OpenClaw thanks @tdjackey for reporting.
{
"severity": "LOW",
"cwe_ids": [
"CWE-15",
"CWE-863"
],
"github_reviewed": true,
"github_reviewed_at": "2026-03-02T22:40:15Z",
"nvd_published_at": null
}