GHSA-V8JW-8W5P-23G3: Authenticated Remote Code Execution in AVideo Plugin Import

The AVideo platform (formerly YouPHPTube) provides a plugin architecture that allows administrators to extend functionality by uploading compressed archives. This feature is handled by the objects/pluginImport.json.php script. The vulnerability resides in how this script processes uploaded ZIP files.

Instead of using secure, native PHP libraries to handle file extraction, the application relies on passing user-supplied file paths directly to the underlying operating system's unzip utility via the exec() function. This implementation fails to enforce strict boundaries on the extraction process.

By crafting a malicious ZIP archive, an attacker can introduce arbitrary files into the application's web root. Since AVideo is a PHP application, the ability to write .php files to a web-accessible directory allows for immediate Remote Code Execution (RCE). The vulnerability combines elements of insecure file upload and command injection risks.

The root cause of this vulnerability is the unsafe implementation of the archive extraction logic in objects/pluginImport.json.php. The application performs a superficial check on the file extension but fails to validate the internal structure or contents of the archive before processing it.

Specifically, the code constructs a shell command using the uploaded file's temporary path and executes it using exec():

// Vulnerable logic pattern
exec("unzip {$path} -d {$destination}");

This approach introduces several critical security flaws:

1. Lack of Content Inspection: The application does not scan the ZIP file for dangerous extensions (e.g., .php, .phtml, .htaccess). If the ZIP contains a PHP web shell, unzip will faithfully extract it to the destination directory.
2. Implicit Trust in 'unzip': The standard unzip utility may allow directory traversal (ZipSlip) if not invoked with specific flags, potentially allowing files to be written outside the intended directory structure.
3. Command Injection: While the primary vector here is the file write, passing unsanitized paths to exec() creates a risk of OS command injection if the filename variables can be manipulated by the attacker.

The following analysis compares the vulnerable implementation with the remediated code from commit b739aeeb9ce34aed9961d2c155d597810f8229db.

Vulnerable Code (Pre-Patch): The original code relied on exec() and failed to validate the extracted files.

// Vulnerable: Direct shell execution
if (strcasecmp($extension, 'zip') == 0) {
    $destination = "{$global['systemRootPath']}plugin/";
    // $path is the temp file path from $_FILES
    exec("unzip {$path} -d {$destination}");
}

Patched Code: The fix replaces the shell command with PHP's native ZipArchive class and introduces rigorous validation logic.

// Remediated: Use ZipArchive and validate contents
$zip = new ZipArchive;
if ($zip->open($path) === TRUE) {
    // 1. Iterate through all files BEFORE extraction
    for($i = 0; $i < $zip->numFiles; $i++) {
        $filename = $zip->getNameIndex($i);
        
        // 2. Prevent Path Traversal and Dangerous Extensions
        if (preg_match('/\\.\\.|\\/|\\\\/', $filename) || 
            preg_match('/\\.(php|phtml|phar|cgi|pl|py|rb|sh|exe|dll|bat|cmd|sh)$/i', $filename)) {
            // Abort if dangerous file found
            return false;
        }
    }
    
    // 3. Safe Extraction
    $zip->extractTo($destination);
    $zip->close();
}

The patch ensures that no file inside the ZIP contains directory traversal characters (..) or executable extensions. It fundamentally changes the mechanism from a blind OS command to a managed, inspected extraction process.

To exploit this vulnerability, an attacker requires administrative access to the AVideo dashboard. The exploitation flow is straightforward due to the lack of server-side validation.

Step 1: Payload Creation The attacker creates a standard ZIP archive containing a PHP web shell. For example, a file named shell.php containing <?php system($_GET['cmd']); ?> is zipped into exploit.zip.

Step 2: Upload The attacker navigates to the Plugin Manager interface and uses the "Import Plugin" feature to upload exploit.zip. The application accepts the file because it has a .zip extension.

Step 3: Execution Upon upload, the server executes unzip, extracting shell.php into the plugin/ directory. The attacker then accesses the shell directly via HTTP:

GET /plugin/shell.php?cmd=id HTTP/1.1
Host: target-avideo.com

If successful, the server responds with the output of the id command, confirming code execution with the privileges of the web server user (www-data).

The impact of this vulnerability is critical, although it is mitigated by the requirement for administrative authentication. Successful exploitation grants the attacker full control over the web application and the underlying server.

Confidentiality: Attackers can read sensitive configuration files, including configuration.php, which typically contains database credentials and API keys.

Integrity: Attackers can modify application source code, inject malware into video streams, or deface the platform.

Availability: The attacker can delete files, drop databases, or shut down the service entirely.

While the requirement for authentication lowers the likelihood of opportunistic attacks, this vector is highly dangerous in scenarios involving compromised admin credentials or insider threats. The CVSS score reflects this with a High severity rating.

Administrators must upgrade AVideo immediately to a version including the fix. The specific patch is located in commit b739aeeb9ce34aed9961d2c155d597810f8229db.

Primary Fix: Update the AVideo instance using the built-in updater or by pulling the latest changes from the official GitHub repository. The fix removes the exec call and enforces strict file extension whitelisting.

Defense in Depth:

1. Disable exec(): If possible, disable the exec(), system(), and passthru() functions in the php.ini configuration file (disable_functions) to prevent command execution vulnerabilities.
2. File Permissions: Ensure the plugin/ directory is not writable by the web server user if plugin uploads are not frequently required, or restrict execution of PHP files in upload directories using .htaccess or Nginx configuration.
3. WAF Rules: Deploy Web Application Firewall rules to detect and block uploads of ZIP files containing PHP extensions or suspect payloads.