GHSA-8FW8-Q79C-FP9M: Unauthenticated Local File Inclusion and Remote Code Execution in AVideo API

The AVideo platform (formerly YouPHPTube) exposes an application programming interface (API) for various administrative and operational functions. The API architecture routes incoming HTTP requests through a central entry point before dispatching them to specific plugin handlers. The vulnerability resides within the locale management endpoint, which processes language translation files for the application interface.

This specific flaw is classified under CWE-22 (Improper Limitation of a Pathname to a Restricted Directory) and CWE-98 (Improper Control of Filename for 'include/require' Statement). Attackers can interact with the vulnerable endpoint without supplying any authentication credentials. The API entry script deliberately bypasses same-domain security checks for these requests, ensuring the endpoint remains entirely public-facing.

The core issue stems from the application dynamically constructing file paths using unvalidated HTTP parameters. When an attacker provides a crafted string containing directory traversal sequences, the application incorporates these sequences into the final file path. The resulting path is then passed directly to a PHP include directive.

As of version 26.0, the vendor has not released an official patch for this vulnerability. Deployments of AVideo running version 26.0 or earlier remain susceptible to exploitation. Organizations utilizing this software must apply manual mitigations to prevent unauthenticated access to the vulnerable API handler.

The vulnerability originates in the API parameter handling mechanism located at plugin/API/get.json.php. This script consolidates GET, POST, and JSON payload parameters into a single $parameters array. Concurrently, the script sets the $global['bypassSameDomainCheck'] variable to 1. This specific configuration overrides standard access controls, permitting external, unauthenticated cross-origin requests to reach the internal API functions.

Once the request passes the initial gateway, execution flows to the get_api_locale() method defined in plugin/API/API.php. The method retrieves the user-supplied language parameter from the unified $parameters array. The application converts this parameter to lowercase but performs no structural validation, canonicalization, or sanitization to remove directory traversal characters.

The application constructs the target file path by concatenating the system root path, the string locale/, the unvalidated language parameter, and the .php extension. The code attempts to validate the file's existence using the file_exists() function. This function strictly checks if the file exists on the filesystem at the resolved path, but it does not restrict the path to the intended directory.

Following the file_exists() check, the application executes the file using the PHP include statement. Because the validation step only confirms existence and not location, an attacker can supply traversal sequences (e.g., ../) to escape the locale/ directory and include any existing PHP file on the underlying filesystem.

The vulnerable code sequence exists within the get_api_locale() function in plugin/API/API.php (approximately lines 5009–5023). The implementation directly handles the $parameters['language'] value without applying necessary security controls.

$parameters['language'] = strtolower($parameters['language']);
$file = "{$global['systemRootPath']}locale/{$parameters['language']}.php";
if (!file_exists($file)) { 
    return new ApiObject("This language does not exists"); 
}
include $file;

The fundamental flaw in this snippet is the assumption that the language parameter will only contain legitimate locale identifiers like en or pt_BR. If an attacker submits ../view/about, the $file variable evaluates to [systemRootPath]locale/../view/about.php. The filesystem resolves this to [systemRootPath]view/about.php. The file_exists() check succeeds because about.php is a valid file, and the application subsequently includes it.

Because an official patch is unavailable, developers must implement a manual fix. A robust remediation involves validating the input against a strict allowlist or using basename() to strip all path information. The following hypothetical patch demonstrates a secure implementation using the basename() function to prevent directory traversal:

// SECURE IMPLEMENTATION
$sanitized_language = basename(strtolower($parameters['language']));
$file = "{$global['systemRootPath']}locale/{$sanitized_language}.php";
if (!file_exists($file) || !preg_match('/^[a-z_]+$/i', $sanitized_language)) { 
    return new ApiObject("Invalid language specified"); 
}
include $file;

The execution flow of the vulnerable implementation is illustrated below:

Exploitation requires no authentication, authorization, or prior interaction with the target system. An attacker merely needs network access to the web interface. The exploitation process begins by sending a standard HTTP GET request to the get.json.php endpoint, specifying locale as the APIName and injecting the payload into the language parameter.

To verify the vulnerability, an attacker can attempt to include a known existing file within the application directory structure. The following HTTP request demonstrates an LFI attack targeting the about.php file:

GET /plugin/API/get.json.php?APIName=locale&language=../view/about HTTP/1.1
Host: target.example.com

The server responds by executing about.php and returning its rendered HTML within the API response. This behavior confirms the presence of the traversal vulnerability and the ability to execute arbitrary PHP files on the filesystem.

To escalate this Local File Inclusion to Remote Code Execution (RCE), the attacker must introduce malicious PHP code onto the filesystem. This is typically achieved by uploading a file through another application feature (such as a profile picture or video upload) or by locating an existing writable directory. If the attacker uploads a file named shell.php containing <?php system($_GET['x']); ?> into the videos/locale/ directory, they can execute arbitrary system commands using the following payload:

GET /plugin/API/get.json.php?APIName=locale&language=../videos/locale/shell&x=whoami HTTP/1.1
Host: target.example.com

The vulnerability presents a High severity risk to the confidentiality of the affected system. The Local File Inclusion capability allows an unauthenticated attacker to read sensitive PHP files within the web root. By utilizing PHP wrappers (e.g., php://filter/convert.base64-encode/resource=), attackers can extract the application's source code, database credentials, and internal configuration files without executing them.

The integrity and availability impacts are classified as Low under the CVSS v3.1 scoring matrix for the baseline LFI condition. The attacker can execute existing PHP files, which may alter the application state depending on the included file's logic. However, the attacker does not have arbitrary write capabilities strictly through the LFI vector itself.

If the attacker successfully escalates the LFI to Remote Code Execution by including user-controlled files, the impact increases significantly. RCE grants the attacker the ability to execute arbitrary operating system commands within the security context of the web server process. This level of access facilitates full server compromise, persistent backdoor installation, and lateral movement into the internal network.

Due to the unauthenticated nature of the exploit and the straightforward exploitation path, this vulnerability is highly suitable for automated exploitation. Systems exposing the AVideo API to the public internet face immediate risk of compromise by opportunistic attackers scanning for vulnerable endpoints.

As an official patch has not been released, administrators must implement manual mitigations to secure vulnerable deployments. The most effective immediate mitigation is to block access to the vulnerable API endpoint using a Web Application Firewall (WAF) or reverse proxy. Administrators should configure rules to inspect the query string for APIName=locale and drop requests containing directory traversal sequences (../, ..\, or URL-encoded equivalents) in the language parameter.

Alternatively, administrators with file-level access to the deployment can manually modify the source code to neutralize the vulnerability. Open the plugin/API/API.php file, locate the get_api_locale() function, and wrap the $parameters['language'] variable with the basename() function. This modification strips directory paths from the input, ensuring the application only searches for the file within the intended locale/ directory.

Organizations should review their web server configurations to restrict execution permissions in directories intended for file uploads. Directories such as video storage and user uploads must not permit the execution of PHP scripts. Implementing strict MIME-type validation and storing uploaded files outside the web root further reduces the risk of LFI-to-RCE escalation.

For detection, security teams should implement network monitoring rules targeting the specific API endpoint. Intrusion Detection Systems (IDS) can flag HTTP GET requests directed at /plugin/API/get.json.php that contain traversal patterns in the language parameter. Analyzing web server access logs for anomalous requests to this endpoint will identify historical exploitation attempts.