OpenClaw EUVD-2026-87520

Exploitation requires that the operator has previously granted a reusable 'allow-always' exec approval for a command, and that an attacker can steer the agent into reusing that approval against a different working directory (unreviewed files or repositories). It is NOT exploitable against a default install with no standing approvals. Limiting factors: the pre-existing allow-always grant must exist; the attacker must influence agent behavior (passive user/agent interaction, UI:P); and impact is bounded by what the already-approved command can do. Affects OpenClaw versions before 2026.8.1.

This is a genuine but conditional authorization flaw (CWE-863) in OpenClaw, an open-source AI-agent framework, not a broadly-exploitable network vulnerability. The vendor CVSS 4.0 vector (8.5, AV:N/AC:L/PR:L/UI:P/VC:H/VI:H/VA:N) drives the high score, but it likely overstates real-world ease: exploitation is not a clean remote-attacker scenario - it requires a pre-existing operator 'allow-always' exec approval AND a steered/misdirected agent turn to reuse that approval in an unintended working directory. That is closer to AC:H than AC:L, which is why my independent 3.1 assessment lands near 7.3 rather than the vendor's 8.5. No EPSS score, no CISA KEV listing, and no public exploit code were provided - so there is no public exploit identified at time of analysis and no evidence of active exploitation. Signals are internally consistent (all point to a real-but-gated integrity/confidentiality issue), with the only conflict being attack complexity: the description's 'must already have an allow-always approval' precondition contradicts the vendor's AC:L. Treat as a real hardening priority for OpenClaw operators who use exec approvals, but not an emergency; the niche deployment footprint further lowers aggregate risk.

An OpenClaw operator previously granted an 'allow-always' approval for a specific exec command (e.g. a build or lint tool) while working in a trusted repository. An attacker who can steer the agent - via a crafted message, task, or file - causes that same approved command to run in a different, unreviewed directory, so the reused approval now operates on sensitive or attacker-chosen files with materially different effect. No public proof-of-concept was provided; exploitation depends on the prior approval and the passive user interaction of the agent acting on attacker-influenced input.