CVE-2026-92580

AVideo through 29.0 contains a stored OS command injection (CWE-78) in the CloneSite plugin: cloneClient.json.php builds the command 'sshpass -p <password> rsync ...' with a plain str_replace and no shell escaping, so a single quote in the stored SSH password breaks out of the quoted argument and injects arbitrary shell commands. The password is saved through the admin-only objects/pluginAddDataObject.json.php endpoint, whose only CSRF defense is a no-op when requests appear to originate from loopback (e.g., behind a same-host TLS-terminating reverse proxy with $global['trustedProxies'] unset) or when an attacker-controlled application is co-hosted on the same hostname; on HTTPS the session cookie is SameSite=None, so a cross-site POST carries the admin's session. An unauthenticated attacker who lures a logged-in administrator into saving a malicious SSH password (and an attacker-controlled cloneSiteURL) gains arbitrary command execution when the plugin's documented crontab entry runs, with the privileges of the crontab owner (commonly root or www-data). Only deployments with the CloneSite plugin enabled and its crontab installed are exploitable, and default single-process Apache deployments are reported as not CSRF-exploitable. The flaw is confirmed at master HEAD (commit 8963b6a1); no public PoC is known, it is not in CISA KEV, and no patched version is available.

What to do: No patched release exists yet, so disable the CloneSite plugin and remove its crontab entry unless strictly required. Otherwise restrict access to objects/pluginAddDataObject.json.php and plugin/CloneSite/cloneClient.json.php, set $global['trustedProxies'] correctly so the loopback CSRF bypass does not trigger, and reject single quotes or shell metacharacters in the stored SSH password. Because the injected command runs as the crontab owner (often root or www-data), monitor those accounts and audit recent crontab-driven CloneSite activity for tampering.