OpenClaw Approval and Exec Authorization Bypasses

OS command execution on paired Chrome nodes is possible in OpenClaw 2026.5.1 through 2026.7.0 because the googlemeet.chrome node command accepts caller-supplied audio command arrays and runs them on the paired node without passing through the normal system.run exec-approval flow. An authenticated, tool-enabled agent (CVSS vector PR:L) that is permitted to invoke googlemeet.chrome - in a deployment where the Google Meet plugin is enabled, a Chrome node is paired, and googlemeet.chrome is on the allowed node commands list - can launch attacker-chosen processes on that node, with full confidentiality, integrity, and availability impact on the paired node (assessed CVSS 3.1 8.6; vendor CVSS 4.0 base 8.7). No public exploit code has been identified at time of analysis and the issue is not in CISA KEV; the flaw is fixed in 2026.7.1, and removing googlemeet.chrome from allowed node commands or disabling the Google Meet plugin fully mitigates it.

OpenClaw (npm package openclaw) before 2026.7.1 misbinds Signal approval reactions to the wrong message, so a reaction an approver places on ordinary outbound text can be interpreted as approving or denying a structured host-action request that happens to be pending in the same conversation. Exploitation requires an authenticated participant acting as approver (PR:L), deliberate user interaction via a reaction (UI:P), and precise timing where unrelated outbound messages and a pending approval coexist (AC:H, AT:P), which is why the CVSS 4.0 base score is 7.5 rather than critical. The flaw does not grant any party new authority and does not change the legitimacy of correctly identified approvers; impact is bounded by whatever host actions the OpenClaw process is authorized to perform for the specific pending request. Vendor-released patch: 2026.7.1; no public exploit identified at time of analysis and the issue is not in CISA KEV.