Executive Summary

[{'type': 'paragraph', 'content': 'CVE-2026-33354 is a high-severity vulnerability in the WWBN AVideo platform (versions up to 26.0) that allows an authenticated uploader to read arbitrary local files on the server.'}, {'type': 'paragraph', 'content': 'The vulnerability exists in the POST endpoint `/objects/aVideoEncoder.json.php`, which accepts a `chunkFile` parameter intended for staged upload chunks. Instead of restricting this parameter to trusted server-generated chunk locations, it accepts arbitrary local filesystem paths that pass a permissive validation function.'}, {'type': 'paragraph', 'content': "An attacker who is authenticated and owns at least one editable video can specify a local file path in the `chunkFile` parameter. The server then copies the chosen local file into the attacker's public video storage path, making the file accessible for download over HTTP."}, {'type': 'paragraph', 'content': 'This effectively enables arbitrary local file read access, allowing attackers to access sensitive files such as private keys.'}] [1]

Useful 0 Not Useful 0

Impact Analysis

This vulnerability can have serious impacts including unauthorized disclosure of sensitive local files on the server.

• Confidentiality breach: Attackers can read sensitive files such as private keys, configuration files, or other data stored on the server.
• Potential compromise of server security by exposing private keys or credentials.
• Loss of trust and potential damage to the reputation of the organization operating the affected AVideo instance.
• The vulnerability requires only low privileges (an authenticated uploader) and no user interaction, making exploitation relatively easy for authorized users.

Useful 0 Not Useful 0

Compliance Impact

I don't know

Useful 0 Not Useful 0

Detection Guidance

This vulnerability can be detected by attempting to exploit the `chunkFile` parameter in the POST request to `/objects/aVideoEncoder.json.php` as an authenticated uploader. By sending a crafted POST request with a local file path in the `chunkFile` parameter, you can check if the server copies the specified local file into the public video storage path, making it accessible over HTTP.

A practical detection method involves using curl commands to simulate the exploit steps: logging in as an uploader, uploading a video to get a `videos_id`, then sending a POST request with the `chunkFile` parameter set to a sensitive local file path (e.g., the TLS private key file). If the file contents are accessible via the returned public video URL, the vulnerability exists.

• Use curl to log in and obtain authentication cookies.
• Upload a video to obtain a `videos_id`.
• Send a POST request to `/objects/aVideoEncoder.json.php` with parameters `videos_id=<your_video_id>`, `format=mp4`, and `chunkFile` set to a local file path.
• Attempt to download the resulting media file from the public video URL and check if it contains the contents of the specified local file.

Useful 0 Not Useful 0

Mitigation Strategies

Immediate mitigation involves applying strict validation and restrictions on the `chunkFile` parameter to prevent arbitrary local file reads. Specifically, the following steps are recommended based on the available patch:

• Implement canonicalization of the `chunkFile` path using `realpath()` to resolve symbolic links and relative components.
• Restrict allowed paths to a strict allowlist of temporary directories such as those returned by `getTmpDir()` and `sys_get_temp_dir()`.
• Ensure the resolved path either exactly matches or is a subdirectory of the allowed temporary directories.
• Reject and log any requests where the `chunkFile` path is outside the allowed directories or if `realpath()` fails.

Additionally, increasing the maximum execution time for video uploads and encoding processes can improve robustness but does not directly mitigate the vulnerability.

Since no patched versions are available as of the report, these code-level mitigations should be applied promptly to prevent exploitation.

Useful 0 Not Useful 0