GoClaw EUVD-2026-45377

Exploitation requires low-privileged authenticated access to GoClaw (PR:L per the CVSS 4.0 vector) - unauthenticated exploitation is not supported by available data. The attacker must be able to submit requests to the execution approval interface that invokes matchesAllowlist and extractBin in internal/tools/exec_approval.go; environments where GoClaw's exec approval endpoint is not network-exposed or is restricted to highly trusted accounts have substantially reduced exposure. No special non-default configuration is required beyond having GoClaw deployed and reachable over the network. Exploitation is limited by the low-privilege authentication requirement and by the niche deployment footprint of the product itself.

The CVSS 4.0 base score of 5.3 (Medium) reflects network-reachable exploitation (AV:N) at low complexity (AC:L) with low-privilege authentication required (PR:L) and no user interaction (UI:N), producing limited but non-trivial impact across confidentiality, integrity, and availability (VC:L/VI:L/VA:L). The E:P supplemental metric confirms a public proof-of-concept exists, elevating practical urgency above the raw numeric score alone. No CISA KEV listing exists, so widespread active exploitation is not confirmed. The combination of low attack complexity, network accessibility, a public POC, and the security-relevant nature of the bypassed control (execution allowlist) makes this a credible lateral movement or privilege-chaining vector within environments running GoClaw. However, GoClaw is a niche product with limited enterprise footprint, substantially reducing aggregate exposure. The integrity impact of allowlist bypass is the most consequential signal here; confidentiality and availability impacts are secondary consequences of unauthorized execution.

An attacker with low-privileged access to a GoClaw instance submits a crafted binary name in an execution approval request - for example, a name containing path traversal sequences or encoding that the extractBin function normalizes differently than matchesAllowlist evaluates. The allowlist check passes because it resolves the name to a permitted entry, while the actual execution step resolves it to a different, unauthorized binary. A public proof-of-concept demonstrating this technique is referenced in GitHub issue #1213.