A saved password becomes shell syntax
AVideo’s CloneSite plugin copies a site’s database and media. When configured to use rsync, a file-transfer utility, the clone client places a saved SSH password into a shell command without escaping it. An attacker who can cause that configuration to be saved under an administrator session can plant password text that executes operating-system commands during a later clone operation.
The declared affected range is AVideo 29.0 and earlier, with master commit 8963b6a1 also identified as affected. Direct confirmation covers version 29.0; the other versions in the declared range were not individually confirmed.
What must happen before the password executes
The configuration endpoint, objects/pluginAddDataObject.json.php, accepts a plugin row id and configuration JSON in object_data. It checks User::isAdmin(), so writing the malicious configuration requires an administrator session. The attacker must either control such a session or induce a logged-in administrator to submit the configuration through the conditional cross-site request forgery route discussed below.
The endpoint stores the configuration in the plugins table through encryptIfNeed(). The password field, cloneSiteSSHPassword, uses an encrypted value structure. Encryption changes the stored representation, but later decryption recovers the attacker’s original characters, including characters meaningful to a shell.
Saving the password does not itself execute a command. CloneSite must be enabled, and its useRsync setting must be true. A clone relationship must also be active: plugin/CloneSite/cloneServer.json.php can register a pending entry, and plugin/CloneSite/changeStatus.json.php activates it in clone_SitesAllowed. A pending entry alone is insufficient.
The clone client must then run through an administrator HTTP request to plugin/CloneSite/cloneClient.json.php or a scheduled command-line invocation with a valid myKey. During the handshake with the clone server, Clones::thisURLCanCloneMe() checks that the requesting site’s URL has an entry with active status a and that its key matches. The injected password does not bypass this handshake.
After a successful handshake, the clone flow downloads and imports the database dump before reaching the rsync branch. These dependencies matter: a stored malicious password becomes an execution opportunity only when a subsequent clone run reaches the vulnerable command construction.
Why the shell interprets the password as code
The clone client uses rsync to transfer files over Secure Shell (SSH), with sshpass supplying the SSH password. Several other inputs receive character allowlists, which restrict values to approved characters. These include file and directory fields and the clone-site URL; the rsync branch also filters cloneSiteSSHUser and cloneSiteSSHIP.
The password does not receive equivalent protection at the shell boundary. decryptIfNeed() only decrypts it. The handler then uses str_replace() to insert cloneSiteSSHPassword->value directly into a single-quoted password argument and passes the resulting command string to exec().
Single quotes normally tell a shell to treat the enclosed text literally. An embedded single quote in the unescaped password can end that quoted region, allowing subsequent text to be interpreted as shell syntax. The attacker can introduce command substitution, a shell feature that runs a command and substitutes its output into the surrounding command line.
The shell evaluates that substitution while processing the command line, independently of whether sshpass or rsync succeeds. The failure is therefore in the construction of the shell command, before successful file transfer is required. Password encryption does not prevent it because the decrypted text still reaches that command unchanged.
The CVE record characterizes this password field as a remaining command-injection entry point after the fix for CVE-2026-41304. This CVE concerns that residual password-handling flaw.
CSRF is a conditional route to the configuration write
Cross-site request forgery (CSRF) makes a logged-in user’s browser submit an attacker-chosen request using that user’s session. Here, it is a possible way to obtain the required administrator-context configuration write; it does not remove the clone handshake or later execution requirements.
The configuration endpoint has no CSRF token, a request value used to establish that a state-changing action was intentionally submitted through the application. It also does not call forbidIfIsUntrustedRequest(). Although Object::save() in objects/Object.php implements an isUntrustedRequest() same-origin check, intended to reject requests from outside the expected web origin, ignoreTableSecurityCheck() exempts both plugins and clone_SitesAllowed. Consequently, that database-write check does not protect this configuration-saving path. The administrator check still applies.
The advisory’s CSRF route depends on particular deployments involving a same-host TLS reverse proxy—a front end that handles HTTPS before forwarding requests—or same-site co-hosting, where content shares a browser site. It also depends on HTTPS session cookies using SameSite=None. The reverse-proxy explanation additionally requires trustedProxies to be unset.
These conditions must be interpreted by version. The 29.0 tag sets session cookies with Secure and SameSite=None: the first limits cookie transmission to HTTPS, while the second relaxes the cookie’s cross-site restriction. However, 29.0 lacks the loopback trust logic and trustedProxies configuration used in the advisory’s reverse-proxy explanation; that logic is attributed to master commit 8963b6a1. The CSRF route was not directly confirmed, and the advisory describes default single-process Apache deployments as not exploitable through that route. An unauthenticated attacker therefore cannot be assumed to have a working delivery path on every affected installation.
Execution privileges and containment
Injected commands run with the clone client’s process privileges. Confirmed execution used an administrator HTTP trigger and ran as the web process, www-data, allowing reads and writes within that process’s permissions, including creation of web-accessible files. The demonstrated scope was the web application container; compromise of the host or a separate database container was not established.
A scheduled clone run would inherit the job owner’s privileges. The advisory describes jobs owned by either www-data or root; execution as root on the host could lead to complete host compromise. Unattended scheduled execution and root execution were not confirmed, and both depend on the actual job configuration and execution environment.
Because the password is stored, later eligible clone runs can execute the injected command again while the malicious configuration remains in place.
Disabling CloneSite makes the vulnerable plugin path unreachable. Setting useRsync to false also prevents entry into the affected rsync branch. These are configuration containment measures supported by the execution prerequisites; they do not repair the password’s treatment during command construction. The advisory version information does not identify a patched release.