CVE-2026-34369: WWBN AVideo Auth Bypass Vulnerability

CVE-2026-34369 Overview

WWBN AVideo is an open source video platform. In versions up to and including 26.0, the get_api_video_file and get_api_video 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.

Critical Impact

Unauthenticated attackers can bypass password protection on videos by directly calling API endpoints, exposing private video content without requiring any credentials.

Affected Products

• WWBN AVideo versions up to and including 26.0
• All instances using password-protected video functionality

Discovery Timeline

• 2026-03-27 - CVE CVE-2026-34369 published to NVD
• 2026-03-31 - Last updated in NVD database

Technical Details for CVE-2026-34369

Vulnerability Analysis

This vulnerability is classified under CWE-862 (Missing Authorization). The core issue lies in an inconsistent security model between the web-based playback interface and the API endpoints. While the web interface properly enforces password verification through the CustomizeUser::getModeYouTube() hook before granting access to protected videos, the API endpoints get_api_video_file and get_api_video were implemented without equivalent authorization checks. This creates a bypass where attackers can circumvent password protection entirely by directly interacting with the API layer.

Root Cause

The root cause is a missing authorization check in the API code path within plugin/API/API.php. The developers implemented password verification logic in the web playback flow but failed to extend this security control to the corresponding API endpoints. This oversight allows direct API calls to retrieve video playback URLs, HLS manifests, and direct MP4 links without validating the video password.

Attack Vector

The attack is network-based and requires no authentication or user interaction. An attacker can exploit this vulnerability by:

1. Identifying the videos_id parameter for a target password-protected video
2. Directly calling the get_api_video_file or get_api_video API endpoints with the video ID
3. Receiving full playback sources including direct MP4 URLs and HLS manifests without password verification

The security patch adds video password verification to the API code path:

         global $global;
         $obj = $this->startResponseObject($parameters);
         $obj->videos_id = $parameters['videos_id'];
+        $video = new Video('', '', $obj->videos_id);
         if (!self::isAPISecretValid()) {
             if (!User::canWatchVideoWithAds($obj->videos_id)) {
                 return new ApiObject("You cannot watch this video");
             }
+            $storedPassword = $video->getVideo_password();
+            if (!empty($storedPassword) && !Video::verifyVideoPassword((string)($parameters['video_password'] ?? ''), $storedPassword)) {
+                return new ApiObject("Video password required");
+            }
         }
-        $video = new Video('', '', $obj->videos_id);
         $obj->filename = $video->getFilename();
         $obj->duration_in_seconds = $video->getDuration_in_seconds();
         $obj->title = $video->getTitle();

Source: GitHub Code Commit

Detection Methods for CVE-2026-34369

Indicators of Compromise

• Unusual API call patterns to get_api_video_file or get_api_video endpoints without corresponding web session activity
• Direct access to password-protected video content from IP addresses that never authenticated via the web interface
• High volume of API requests targeting multiple video IDs in rapid succession
• API access logs showing requests for protected videos without the video_password parameter

Detection Strategies

• Monitor API endpoint access logs for calls to get_api_video_file and get_api_video that don't originate from authenticated web sessions
• Implement anomaly detection for bulk video ID enumeration attempts across API endpoints
• Correlate API access logs with web authentication logs to identify discrepancies
• Deploy web application firewall rules to flag suspicious API request patterns targeting video endpoints

Monitoring Recommendations

• Enable verbose logging for all API endpoint access in AVideo
• Set up alerts for API calls accessing password-protected videos without the password parameter
• Monitor for unusual download patterns of video content that bypasses normal playback metrics
• Review API access logs regularly for unauthorized access to protected content

How to Mitigate CVE-2026-34369

Immediate Actions Required

• Update WWBN AVideo to a version containing commit be344206f2f461c034ad2f1c5d8212dd8a52b8c7
• Audit access logs for potential exploitation of password-protected videos
• Review all password-protected video content to assess potential exposure
• Notify content owners if unauthorized access to their protected videos is detected

Patch Information

The vulnerability is fixed in commit be344206f2f461c034ad2f1c5d8212dd8a52b8c7. This patch implements video password verification within the API code path by calling Video::verifyVideoPassword() before returning video playback sources. Organizations should update to a version containing this fix immediately. For detailed patch information, refer to the GitHub Security Advisory.

Workarounds

• Implement API rate limiting to slow enumeration attacks until patching is complete
• Deploy a web application firewall (WAF) to block or monitor direct API calls to affected endpoints
• Temporarily disable API access to video endpoints if the feature is not critical to operations
• Consider moving sensitive password-protected videos to a separate, restricted environment until the patch is applied

# Example: Block direct API access to vulnerable endpoints using Apache mod_rewrite
# Add to .htaccess or Apache configuration
RewriteEngine On
RewriteCond %{REQUEST_URI} ^/plugin/API/.*$
RewriteCond %{HTTP_REFERER} !^https://your-domain\.com [NC]
RewriteRule ^.*$ - [F,L]