CVE-2026-92580 in AVideo
Summary
by MITRE • 09/17/2026
In AVideo through 29.0, the CloneSite plugin is vulnerable to stored OS command injection. In plugin/CloneSite/cloneClient.json.php (line ~270) the stored SSH password is substituted into the command string `sshpass -p '{password}' rsync ...` with a plain str_replace and no escaping, so a single quote in the password breaks out of the quoted word and injects arbitrary shell. The password is written through the admin-only endpoint objects/pluginAddDataObject.json.php, whose only CSRF defense (isUntrustedRequest()/forbidIfIsUntrustedRequest()) is a no-op when the request source appears to be loopback — as happens 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 issued with SameSite=None, so a cross-site POST carries it. An unauthenticated remote attacker can therefore lure an authenticated administrator into planting a malicious password (and an attacker-controlled cloneSiteURL), after which the plugin's documented crontab entry executes the injected command with no further administrator action, as the crontab owner (commonly root or www-data). Exploitation requires the CloneSite plugin to be enabled with the documented crontab installed and one of the above CSRF channels; default single-process Apache deployments are reported as not CSRF-exploitable. This is a residual sink of CVE-2026-41304. The issue is confirmed at master HEAD (8963b6a1); no patched version is available.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 09/17/2026
The vulnerability identified in AVideo versions through 29.0 involves a critical stored operating system command injection flaw within the CloneSite plugin, specifically located in the file cloneClient.json.php around line 270. This security defect arises from improper handling of user-supplied input during the execution of remote synchronization tasks. The application utilizes the sshpass utility to facilitate SSH connections by passing an authentication password directly into a shell command string formatted as `sshpass -p '{password}' rsync ...`. Crucially, this substitution is performed using a basic str_replace function without any sanitization or escaping mechanisms. Consequently, if the inputted password contains single quote characters, it breaks out of the quoted context within the shell command line, allowing an attacker to inject arbitrary operating system commands that are subsequently executed by the underlying system interpreter.
The attack vector for this vulnerability is multifaceted, relying on both a stored injection mechanism and a cross-site request forgery bypass. The malicious password payload is initially written through the admin-only endpoint objects/pluginAddDataObject.json.php. While this endpoint implements CSRF protection via functions such as isUntrustedRequest() or forbidIfIsUntrustedRequest(), these defenses are effectively neutralized in specific deployment configurations. Specifically, when requests originate from loopback addresses due to a same-host TLS-terminating reverse proxy where the global trusted proxies configuration remains unset, the CSRF checks fail to validate the request origin properly. Additionally, on HTTPS connections, session cookies are issued with SameSite=None attributes, which permits cross-site POST requests to carry valid authentication sessions. This allows an attacker-controlled application co-hosted on the same hostname or a reverse proxy scenario to forge administrative actions without user interaction beyond initial lure tactics.
The operational impact of this vulnerability is severe due to its persistent and automated nature. An unauthenticated remote attacker can exploit these conditions by luring an authenticated administrator into configuring a malicious cloneSiteURL and password combination through the administration interface. Once stored, the vulnerability does not require further manual intervention from the victim because the CloneSite plugin includes a documented crontab entry that executes synchronization tasks automatically at scheduled intervals. This automated execution ensures that the injected command runs with elevated privileges, typically as root or www-data depending on the web server configuration. The persistence of this threat means that even if the administrator is unaware of the compromise, the system will continuously attempt to execute the malicious payload during each cron cycle, potentially leading to full remote code execution and complete control over the affected host.
This issue represents a residual sink related to CVE-2026-41304, indicating it may be part of a broader pattern of security deficiencies in how AVideo handles external integrations and command execution contexts. The flaw aligns with CWE-78 Improper Neutralization of Special Elements used in an OS Command (OS Command Injection) as well as CWE-94 Improper Control of Generation of Code (Code Injection). From the perspective of the MITRE ATT&CK framework, this vulnerability facilitates lateral movement and privilege escalation through T1053 Scheduled Task/Job: Cron and allows for initial access via T1998 Server Software Component. The exploitation relies on specific environmental conditions such as default single-process Apache deployments which are noted as not being susceptible to the CSRF aspect of the attack under standard configurations, highlighting that threat actors must tailor their approach based on the target's infrastructure setup.
Mitigation strategies for this vulnerability focus primarily on immediate remediation steps since no patched version is currently available at master HEAD commit 8963b6a1. Administrators should immediately disable or uninstall the CloneSite plugin if it is not essential to operations, thereby removing both the injection point and the automated execution mechanism via crontab. If the plugin must remain active, strict input validation must be implemented on all password fields before they are passed to system commands, ensuring that special characters like single quotes are properly escaped or rejected. Furthermore, administrators should review their reverse proxy configurations to ensure trusted proxies are correctly defined in global settings, which will restore effective CSRF protections for administrative endpoints. Implementing SameSite=Strict or Lax attributes on session cookies where possible can also reduce the risk of cross-site request forgery attacks against authenticated sessions. Regular auditing of crontab entries and monitoring for unexpected system processes can help detect exploitation attempts early.