OpenClaw EUVD-2026-36315

Three conditions must simultaneously hold for exploitation: (1) the embedded runner policy feature must be active in the OpenClaw configuration - environments not using the embedded runner are not affected; (2) provider aliases must be configured, since the confusion requires an alias to exist that maps to a restricted canonical provider; (3) the attacker must have low-privileged local access to the system running OpenClaw (PR:L per CVSS 4.0, AV:L). Remote unauthenticated exploitation is not possible given the local attack vector. Exploitation is further bounded to integrity impact only - there is no confidentiality or availability consequence even in a successful attack, limiting the practical damage to unauthorized tool invocation within the runner context.

The CVSS 4.0 base score of 4.8 (Medium) with vector AV:L/AC:L/AT:N/PR:L/UI:N/VC:N/VI:L/VA:N/SC:N/SI:L/SA:N accurately reflects the bounded threat model: local access with low privileges, limited integrity-only impact on both the vulnerable system and any downstream subsequent system, and no confidentiality or availability impact. No EPSS data was supplied for this CVE; however, the local-only attack vector makes automated or widespread exploitation infeasible. There is no CISA KEV listing and no proof-of-concept code has been identified, placing this firmly in the category of low operational priority for most organizations. The principal risk is a privileged-escalation-in-policy scenario in environments that rely on embedded runner provider policies as a security boundary - if that boundary is not a trust boundary (e.g., all local users are already trusted), impact is negligible. Defenders should note that the dual integrity signals (VI:L and SI:L) suggest the unauthorized tool access could have cascading effects into subsequent systems if those tools perform write or state-modifying operations.

A low-privileged user with local access to an OpenClaw deployment where provider aliases are active in the embedded runner policy crafts a request that specifies an alias corresponding to a provider whose canonical identity would normally be blocked by their policy. Because the policy engine compares the alias string against other aliases rather than resolving to the canonical identity, the authorization check passes and the user gains access to bundled tools that exceed their permitted provider scope. No public proof-of-concept has been identified at the time of this analysis.