CVE-2026-34362: WWBN AVideo Auth Bypass Vulnerability

CVE-2026-34362 Overview

CVE-2026-34362 is an Insufficient Session Expiration vulnerability affecting WWBN AVideo, an open source video platform. The vulnerability exists in the verifyTokenSocket() function within plugin/YPTSocket/functions.php, where token timeout validation logic has been commented out. This causes WebSocket tokens to never expire despite being generated with a 12-hour timeout, allowing captured or legitimately obtained tokens to provide permanent WebSocket access.

Critical Impact
Attackers with captured WebSocket tokens can maintain persistent access to the platform's real-time connection system indefinitely, even after user accounts are deleted, banned, or demoted from admin status. Admin tokens grant access to real-time connection data for all online users including IP addresses, browser information, and page locations.

Affected Products

WWBN AVideo versions up to and including 26.0
AVideo instances with the YPTSocket plugin enabled
Self-hosted AVideo deployments without the security patch applied

Discovery Timeline

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

Technical Details for CVE-2026-34362

Vulnerability Analysis

This vulnerability represents a classic Insufficient Session Expiration issue (CWE-613) where token lifecycle management is improperly disabled. The verifyTokenSocket() function is designed to validate WebSocket authentication tokens with a 12-hour expiration window. However, the critical validation logic that enforces this timeout was commented out in the codebase, effectively making all WebSocket tokens permanent.

The impact is particularly severe because WebSocket connections provide real-time bidirectional communication with the server. An attacker who obtains a valid admin token—whether through network interception, social engineering, or during legitimate access—can maintain that access indefinitely. This persists even if administrative action is taken against the associated account, such as deletion or banning, since the token validation never checks expiration.

Root Cause

The root cause lies in the verifyTokenSocket() function in plugin/YPTSocket/functions.php where the timeout validation conditional and its return statement were commented out. While the function still checks if the current time falls within the valid token window ($time >= $obj->time && $time <= $obj->timeout), the failure path that should reject expired tokens (return false) was never executed due to being commented out.

Attack Vector

The attack is network-based and requires low-privilege access to initially obtain a WebSocket token. An attacker could exploit this vulnerability through several scenarios:

Token Interception: Capturing a WebSocket token via network monitoring or man-in-the-middle attacks
Insider Threat: A former administrator whose account has been revoked retains access via previously obtained tokens
Account Compromise: Obtaining tokens during temporary account compromise, maintaining access after passwords are changed
Session Theft: XSS or other client-side attacks to steal tokens that remain valid indefinitely

The following patch from commit 5d5237121bf82c24e9e0fdd5bc1699f1157783c5 shows the fix that re-enables token expiration validation:

php

     }
     $time = time();
     if (!($time >= $obj->time && $time <= $obj->timeout)) {
-        //_error_log("verifyToken token timout time = $time; obj->time = $obj->time;  obj->timeout = $obj->timeout");
-        //return false;
+        _error_log("verifyToken token timout time = $time; obj->time = $obj->time;  obj->timeout = $obj->timeout");
+        return false;
     }
     return true;
 }

Source: GitHub Commit Details

The client-side JavaScript was also updated to request fresh tokens instead of reusing potentially stale ones:

javascript

             socketLog('Retrying in', socketConnectRetryTimeout / 1000, 'seconds');

             // Retry connection with exponential backoff
+            // Use startSocket() to fetch a fresh token before reconnecting;
+            // socketConnect() would reuse the stale webSocketURL/webSocketToken which expires in 12h.
             socketConnectTimeout = setTimeout(function () {
                 socketConnectRetryTimeout = Math.min(socketConnectRetryTimeout * 2, 60000); // Increase timeout up to 1 minute
-                socketConnect();
+                startSocket();
             }, socketConnectRetryTimeout);

             // Optionally, add checks for connection timeouts, SSL issues, or network connectivity
             checkNetworkConnection();
             checkSSLIssues(webSocketURL);
         } else {
             socketLog('Socket closed normally, code:', e.code);
+            // Use startSocket() to fetch a fresh token before reconnecting
             socketConnectTimeout = setTimeout(function () {
-                socketConnect();
+                startSocket();
             }, socketConnectRetryTimeout);
         }

Source: GitHub Commit Details

Detection Methods for CVE-2026-34362

Indicators of Compromise

WebSocket connections from IP addresses not associated with active user sessions
WebSocket authentication succeeding for tokens older than 12 hours
Continued WebSocket activity from deleted, banned, or demoted user accounts
Unusual patterns of real-time data access from administrative WebSocket channels

Detection Strategies

Implement logging to track WebSocket token age at connection time and alert on tokens exceeding the expected 12-hour validity window
Cross-reference active WebSocket sessions against current user account status to identify orphaned connections
Monitor for WebSocket connections originating from geographic locations inconsistent with user profiles
Review WebSocket server logs for repeated connections using the same token over extended periods

Monitoring Recommendations

Enable and review the _error_log() output for verifyToken token timeout messages after applying the patch
Implement real-time alerting for WebSocket connections from accounts that have been modified (banned, deleted, or privilege changes)
Deploy network monitoring to detect WebSocket traffic patterns indicative of token replay attacks
Audit WebSocket connection logs periodically to identify tokens with anomalously long lifespans

How to Mitigate CVE-2026-34362

Immediate Actions Required

Update to the patched version of WWBN AVideo that includes commit 5d5237121bf82c24e9e0fdd5bc1699f1157783c5
Invalidate all existing WebSocket tokens by regenerating server-side token secrets
Review admin account activity logs for any suspicious real-time data access
Audit all user accounts with elevated privileges and verify their current authorization status

Patch Information

The vulnerability is fixed in commit 5d5237121bf82c24e9e0fdd5bc1699f1157783c5. This patch re-enables the token timeout validation in plugin/YPTSocket/functions.php and updates the client-side JavaScript in plugin/YPTSocket/script.js to fetch fresh tokens upon reconnection rather than reusing potentially expired ones. Administrators should update their AVideo installation to include this commit or any subsequent release containing the fix.

For detailed patch information, see the GitHub Security Advisory GHSA-2mg4-pfgx-64cf.

Workarounds

If immediate patching is not possible, manually uncomment the timeout validation code in plugin/YPTSocket/functions.php as shown in the patch
Disable the YPTSocket plugin entirely if real-time WebSocket functionality is not critical to operations
Implement network-level controls to restrict WebSocket endpoint access to trusted IP ranges
Regularly rotate WebSocket token generation secrets to limit the lifetime of any captured tokens

bash

# Configuration example - Manual patch application
cd /path/to/avideo
git fetch origin
git cherry-pick 5d5237121bf82c24e9e0fdd5bc1699f1157783c5
# Restart web services to apply changes
systemctl restart apache2
# Or for nginx with php-fpm
systemctl restart php-fpm
systemctl restart nginx