CVE-2026-43873 in AVideo
Summary
by MITRE • 05/12/2026
WWBN AVideo is an open source video platform. In versions up to and including 29.0, plugin/CloneSite/cloneClient.json.php echoes the local CloneSite shared secret ($objClone->myKey, a constant md5($global['systemRootPath'] . $global['salt'])) into the HTTP response body on every unauthenticated request. The unauthenticated error branch was intended to reject non-admin callers without a valid key, but the rejection message interpolates the expected key before die(). When the victim has CloneSite configured with a remote cloneSiteURL (standard federation/backup setup), the leaked myKey is exactly the credential that authenticates the victim to that remote server's cloneServer.json.php, allowing the attacker to impersonate the victim and trigger a full mysqldump of the remote's database to the remote's public videos/clones/ directory Commit e6566f56a28f4556b2a0a09d03717a719dcb49da contains an updated fix.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 05/12/2026
The vulnerability exists within the AVideo platform's CloneSite plugin functionality, specifically in the cloneClient.json.php file where a critical information disclosure flaw has been identified. This vulnerability affects versions up to and including 29.0 and represents a severe security weakness that undermines the platform's authentication mechanisms. The flaw stems from the improper handling of the local CloneSite shared secret, which is stored in the variable $objClone->myKey and generated as an md5 hash of the system root path concatenated with a global salt value. This secret serves as the primary authentication credential for federated operations between cloned sites, making its exposure particularly dangerous.
The technical implementation error occurs during error handling when the system processes unauthenticated requests. The error branch that should reject non-admin callers actually performs interpolation of the expected key into the rejection message before terminating execution. This design flaw results in the shared secret being directly exposed in the HTTP response body, making it accessible to any attacker who can make unauthenticated requests to the vulnerable endpoint. The vulnerability is exacerbated by the standard federation setup where CloneSite is configured with a remote cloneSiteURL, creating a scenario where the leaked credential authenticates the attacker to the remote server's cloneServer.json.php endpoint.
The operational impact of this vulnerability is catastrophic for systems utilizing the CloneSite plugin in federated configurations. An attacker who discovers the leaked shared secret can impersonate the victim site and execute malicious operations against the remote server. The most severe consequence is the ability to trigger a full database dump operation that exports the remote database contents to the remote server's public videos/clones/ directory. This creates a complete data breach scenario where sensitive information stored in the remote database becomes publicly accessible. The vulnerability essentially transforms a legitimate administrative function into an attack vector that can be exploited without authentication, violating fundamental security principles of access control and credential protection.
The flaw aligns with CWE-200 (Information Exposure) and CWE-312 (Sensitive Data Exposure) classifications, representing a clear violation of information security best practices. From an ATT&CK perspective, this vulnerability maps to T1566 (Phishing) and T1071.004 (Application Layer Protocol: DNS) when considering the initial reconnaissance phase, but more critically to T1078 (Valid Accounts) and T1041 (Exfiltration Over C2 Channel) when examining the exploitation phase. The vulnerability also demonstrates characteristics of T1531 (Account Access Removal) and T1567 (Exfiltration Over Web Service) through the unauthorized database dump functionality. Organizations using AVideo with CloneSite plugin should immediately implement the fix referenced in commit e6566f56a28f4556b2a0a09d03717a719dcb49da, which properly handles the error response without exposing the shared secret. Additionally, system administrators should review all CloneSite configurations and rotate shared secrets for any systems that may have been compromised, while implementing network-level monitoring to detect unauthorized database dump operations.