CVE-2026-33354 in AVideo
Summary
by MITRE • 03/23/2026
WWBN AVideo is an open source video platform. In versions up to and including 26.0, `POST /objects/aVideoEncoder.json.php` accepts a requester-controlled `chunkFile` parameter intended for staged upload chunks. Instead of restricting that path to trusted server-generated chunk locations, the endpoint accepts arbitrary local filesystem paths that pass `isValidURLOrPath()`. That helper allows files under broad server directories including `/var/www/`, the application root, cache, tmp, and `videos`, only rejecting `.php` files. For an authenticated uploader editing their own video, this becomes an arbitrary local file read. The endpoint copies the attacker-chosen local file into the attacker's public video storage path, after which it can be downloaded over HTTP. Commit 59bbd601a3f65a5b18c1d9e4eb11471c0a59214f contains a patch for the issue.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 03/27/2026
CVE-2026-33354 represents a critical arbitrary file read vulnerability in the WWBN AVideo platform affecting versions up to and including 26.0. This vulnerability exists within the `POST /objects/aVideoEncoder.json.php` endpoint which handles staged video upload chunks through a `chunkFile` parameter. The flaw stems from insufficient input validation and path restriction mechanisms that fail to properly sanitize user-supplied file paths. The application's `isValidURLOrPath()` helper function, designed to validate file paths, contains overly permissive logic that accepts local filesystem paths without adequate restrictions. This validation function permits access to critical server directories including `/var/www/`, the application root directory, cache and temporary storage areas, and the videos directory while only blocking `.php` files. The vulnerability specifically impacts authenticated users who can edit their own videos, allowing them to leverage their privileges to read arbitrary local files from the server filesystem. This represents a significant security weakness that violates fundamental principles of secure file handling and access control.
The technical exploitation of this vulnerability requires an authenticated user with video editing privileges to manipulate the `chunkFile` parameter in the upload endpoint. The attacker can specify any local filesystem path that passes the `isValidURLOrPath()` validation, enabling them to read files from sensitive server locations. Once the vulnerable endpoint processes the attacker-controlled path, it copies the specified file into the attacker's public video storage directory, making the content accessible via standard HTTP download requests. This creates a direct pathway for information disclosure that could potentially expose sensitive configuration files, database credentials, application source code, or other confidential data stored within the server's file system. The vulnerability demonstrates poor input validation practices and inadequate path sanitization, which are classified under CWE-22 (Improper Limitation of a Pathname to a Restricted Directory) and CWE-73 (Restriction of Files with Dangerous Extensions). The attack vector aligns with ATT&CK technique T1566.001 (Phishing: Spearphishing Attachment) and T1078.004 (Valid Accounts: Cloud Accounts) when combined with other exploitation methods.
The operational impact of this vulnerability extends beyond simple information disclosure, as it enables attackers to potentially access sensitive server resources that could facilitate further compromise. An attacker could extract configuration files containing database connection strings, API keys, or cryptographic secrets that might be used to escalate privileges or move laterally within the network. The vulnerability also poses risks to application integrity since attackers could read application source code or configuration files that might reveal implementation details useful for additional attacks. Additionally, the ability to read arbitrary files from the server filesystem could lead to privilege escalation opportunities if the application runs with elevated permissions or if sensitive files are accessible to the web server process. The vulnerability affects the platform's core upload functionality and represents a fundamental flaw in the application's security architecture that undermines trust in the system's ability to properly validate and sanitize user input. Organizations using affected versions should immediately implement the patch referenced in commit 59bbd601a3f65a5b18c1d9e4eb11471c0a59214f, which properly restricts file paths to prevent arbitrary local file access and ensures that only legitimate chunk files can be processed through the upload endpoint.
This vulnerability highlights the importance of proper input validation and access control mechanisms in web applications, particularly when handling file operations. The flaw demonstrates how seemingly innocuous functionality like staged file uploads can become a significant security risk when proper validation and sanitization are omitted. The patch implementation should enforce strict path validation that prevents access to sensitive directories and ensures that only files within designated upload areas can be processed. Security teams should conduct comprehensive reviews of similar file handling functions throughout the application to identify and remediate comparable vulnerabilities. The incident underscores the necessity of implementing defense-in-depth strategies that include proper file access controls, input sanitization, and regular security assessments to prevent unauthorized file access and information disclosure. Organizations should also consider implementing additional monitoring and logging for file operations to detect potential exploitation attempts and maintain audit trails for security incident response activities.