Mar 21, 2026·6 min read·4 visits
An unauthenticated attacker can recover AVideo's cryptographic key via an offline brute-force attack against a leaked, time-based salt. This recovered key allows the forgery of AES-encrypted payloads that are subsequently executed by an unprotected eval() sink.
AVideo platforms version 14.3.1 through 20.0 are vulnerable to an unauthenticated Remote Code Execution (RCE) flaw. The vulnerability arises from a chain of information disclosure, predictable cryptographic salt generation, and an unsafe evaluation sink. An unauthenticated attacker can mathematically derive the internal encryption key and forge authenticated payloads to achieve full system compromise.
AVideo relies on custom cryptographic implementations for data protection and internal state management. The platform utilizes an AES-256-CBC encryption scheme to obfuscate internal identifiers and system commands. This mechanism historically relied on securely generated cryptographic material, but subsequent updates introduced a severe degradation in key generation.
The vulnerability chain, tracked as CVE-2025-34433, emerges from a combination of information disclosure, weak cryptographic entropy, and unsafe data evaluation. The system leaks installation timestamps through public API endpoints, which directly compromises the primary encryption seed used by the legacy cryptographic fallback routine. The combination of these flaws exposes the internal cryptographic state to remote derivation.
An unauthenticated attacker leveraging this flaw can mathematically derive the internal encryption key and forge authenticated payloads. The final stage of the attack terminates in an unauthenticated endpoint containing an unprotected eval() sink. This yields full remote code execution in the context of the web application user, enabling total system compromise.
The fundamental failure exists within the cryptographic key derivation process implemented in the application framework. The platform defaults to a legacy salt generation mechanism based on PHP's uniqid() function. This function generates a 13-character hexadecimal string based on the current system time in microseconds, providing strictly deterministic output rather than cryptographic randomness.
The generated salt structure consists of eight hex characters representing the current Unix timestamp in seconds, followed by five hex characters representing the microsecond counter. This design reduces the theoretical entropy from $16^{13}$ to merely $16^5$ ($1,048,576$ possibilities) if the base timestamp is known. The system leaks this base timestamp via multiple public API endpoints, exposing the exact installation second.
Additionally, the AES-256-CBC implementation relies on the absolute system path as the Initialization Vector (IV). The application frequently leaks this path through verbose error messages and public configuration endpoints. The combination of a predictable salt and a known IV effectively reduces the cryptographic strength of the entire platform to a trivial offline brute-force attack.
The vulnerability requires an examination of the encryption function and the specific evaluation sink. A commit introduced in January 2024 established a fallback mechanism that reinstates the legacy, predictable salt if the modern salt parameters are bypassed. This routine forces the application to compute keys using the deterministic time-based string.
// objects/functions.php - Vulnerable Fallback Logic
if ($useOldSalt) {
$salt = $global['salt']; // Predictable uniqid() output
} else {
$salt = empty($global['saltV2']) ? $global['salt'] : $global['saltV2'];
}
$key = hash('sha256', $salt);The primary execution sink resides in the FFmpeg notification handler, introduced in early 2025. This file accepts a base64-encoded payload parameter, decrypts it using the flawed cryptographic routine, and passes the result directly into an eval() statement. The application performs no structural validation or sanitization prior to execution.
// view/admin/notify.ffmpeg.json.php - Unsafe Execution Sink
$data = $_POST['data'];
$decrypted_data = encrypt_decrypt($data, 'd');
// Unsafe evaluation of decrypted payload
eval($decrypted_data);The encryption routine utilizes the openssl_encrypt function configured with the aes-256-cbc cipher algorithm. Cipher Block Chaining (CBC) mode requires an Initialization Vector (IV) to randomize the ciphertext. The application erroneously utilizes a static string, explicitly the installation path variable, truncated or padded to 16 bytes, as the IV for all cryptographic operations.
Using a static and globally discernible IV violates core cryptographic principles, enabling deterministic encryption outcomes. If an attacker encrypts two identical plaintexts, the resulting ciphertexts will be identical. This static IV construction facilitates offline decryption attempts, as the attacker possesses all necessary parameters except the final AES key.
The final AES key is derived via a standard SHA-256 hash of the recovered salt. Once the one million microsecond permutations are hashed and evaluated against the static IV and the targeted oracle, the local attacker completely recovers the internal key state. The application provides no key rotation or forward secrecy, ensuring a single compromised salt affects all historical and future ciphertexts.
The attack sequence begins with an unauthenticated request to a public API endpoint. The attacker parses the JSON response to extract the creation timestamp of the base objects. This timestamp directly corresponds to the first eight hexadecimal characters of the vulnerable system salt.
The attacker then requests a standard video viewing page to capture an encrypted string, specifically the video hash identifier. This string serves as an offline cryptographic oracle. Using the leaked eight-character timestamp, the attacker executes a local brute-force script to iterate through the remaining microsecond possibilities, decrypting the identifier with each derived key until the output matches a valid integer.
Once the correct salt is recovered, the attacker utilizes the known system path as the AES Initialization Vector to encrypt arbitrary PHP code. The finalized payload is transmitted via a POST request to the administrative notification endpoint. The application decrypts the malicious payload using the recovered key material and executes it via the evaluation construct.
The successful exploitation of CVE-2025-34433 results in immediate, unauthenticated Remote Code Execution (RCE) with the privileges of the web server process. This grants the attacker comprehensive read and write access to the application directory, the internal database, and all uploaded media files.
The deterministic nature of the cryptographic failure ensures that exploitation is perfectly reliable across all vulnerable instances. Because the core vulnerability stems from mathematical predictability rather than memory corruption, the exploit bypasses modern exploit mitigation techniques such as ASLR, DEP, and stack canaries. The execution occurs synchronously within the HTTP request lifecycle.
The CVSS v4.0 score of 10.0 accurately reflects the severity of the flaw. The lack of required user interaction, the absence of authentication prerequisites, and the complete loss of confidentiality, integrity, and availability mandate immediate remediation. The known existence of weaponized exploit modules significantly elevates the probability of widespread exploitation.
Administrators must deploy immediate mitigation strategies, as official patches in version 20.0 do not fully resolve the underlying vulnerability. The primary short-term mitigation requires the complete removal or strict access control restriction of the notify.ffmpeg.json.php endpoint. Blocking external access to this file neutralizes the primary execution sink utilized in the attack chain.
Development teams must refactor the encryption function to strictly enforce the use of high-entropy cryptographic keys. The legacy fallback mechanism must be removed entirely, and the application must rely exclusively on a dynamically generated, cryptographically secure salt derived via modern random byte generators.
The secondary remediation phase requires structural code changes to the notification handler. The application must process inbound asynchronous task responses using strictly typed data structures, such as JSON-decoded associative arrays, rather than executing arbitrary serialized logic. Furthermore, the system path variable must be decoupled from the cryptographic IV generation process.
CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:H/SC:H/SI:H/SA:H| Product | Affected Versions | Fixed Version |
|---|---|---|
AVideo WWBN | >= 14.3.1, <= 20.0 | Unpatched |
| Attribute | Detail |
|---|---|
| CVSS v4.0 Score | 10.0 |
| Attack Vector | Network |
| Authentication Required | None |
| Exploit Status | Weaponized |
| Vulnerability Type | Remote Code Execution, Cryptographic Failure |
| Affected Components | encrypt_decrypt() fallback, notify.ffmpeg.json.php |
The application evaluates dynamically generated code based on input that has been encrypted with a predictable key, allowing unauthenticated attackers to execute arbitrary system commands.