CVE-2026-33650: Privilege Escalation via Incorrect Authorization in WWBN AVideo

WWBN AVideo is an open-source video hosting platform utilized for internal and public video distribution. In versions 26.0 and earlier, the application suffers from an incorrect authorization vulnerability mapped to CWE-863. This flaw resides within the video management endpoints, specifically the API responsible for updating video metadata.

The vulnerability allows users provisioned with the "Videos Moderator" role to escalate their privileges. Although this role is strictly intended to toggle video visibility states such as Active, Inactive, or Unlisted, the backend API grants these users broader permissions. This architectural oversight exposes sensitive video management operations to unauthorized modification.

An attacker leveraging this vulnerability can permanently alter the ownership of any video hosted on the platform. By transferring ownership to their own account, the attacker bypasses subsequent ownership verification checks. This logical chain allows the attacker to unilaterally delete content belonging to other users, including system administrators.

The core issue originates from an asymmetric authorization boundary within the videoAddNew.json.php script. This endpoint processes updates to video metadata but implements an excessively permissive authorization gate. The application uses the Permissions::canModerateVideos() function to bypass the more restrictive Video::canEdit() verification logic.

When a request reaches videoAddNew.json.php, the code evaluates whether the requesting user is the video owner or a moderator. The inclusion of the moderator permission check creates a logical vulnerability. It effectively grants moderators the same administrative capabilities over a video object as the original owner.

Deeper within the same script, the application processes ownership transfer instructions. The application logic specifically permits a user to update the users_id attribute of the video object if the Permissions::canModerateVideos() check returns true. Consequently, a moderator can submit a modified users_id parameter to reassign the target video to their own account.

The deletion endpoint, videoDelete.json.php, relies entirely on the Video::canEdit() function to validate authorization. Because the attacker successfully modified the video's underlying users_id attribute in the previous step, the deletion script evaluates the attacker as the legitimate owner. The deletion proceeds without triggering any access control violations.

An examination of the vulnerable codebase reveals the exact nature of the authorization failure. In the unpatched objects/videoAddNew.json.php file, the initial gate check validates the request using a composite logical condition. The code executes if (!Video::canEdit($_POST['id']) && !Permissions::canModerateVideos()), which actively exempts moderators from standard editing constraints.

Further down the execution path, the script handles the metadata payload, including the owner ID assignment. The vulnerable implementation reads if ($advancedCustomUser->userCanChangeVideoOwner || Permissions::canModerateVideos()), followed directly by $obj->setUsers_id($_POST['users_id']). This explicit reliance on the moderator permission object facilitates the unauthorized ownership transfer.

The remediation, introduced in commit 838e16818c793779406ecbf34ebaeba9830e33f8, resolves this discrepancy by strictly enforcing appropriate permission models. The initial gate in videoAddNew.json.php was simplified to if (!Video::canEdit($_POST['id'])), entirely removing the moderator bypass.

Additionally, the patch modifies the authorization checks governing specific metadata fields. The codebase now requires the Permissions::canAdminVideos() validation before permitting modifications to categories, user groups, and ownership. This change ensures that only users with explicit administrative privileges can reassign video ownership.

Exploitation requires the attacker to possess an active account configured with the PERMISSION_INACTIVATEVIDEOS permission. The attacker must first identify the unique id parameter of the target video they intend to hijack. This ID is typically exposed in the platform's public-facing URLs or standard API responses.

The attack sequence begins with a crafted HTTP POST request directed at the /objects/videoAddNew.json.php endpoint. The attacker includes the target video's id and their own user ID in the users_id parameter. This request manipulates the application state, successfully severing the original owner's control over the video object.

To demonstrate the full impact, the attacker proceeds to the deletion phase. The attacker issues a second HTTP POST request to the /objects/videoDelete.json.php endpoint, supplying only the hijacked video's id. The application evaluates the attacker's newly established ownership and permanently removes the video from the platform.

The exploitation flow requires no advanced tooling and can be executed using standard web proxies or command-line HTTP clients. The attack leaves minimal traces beyond standard application access logs, complicating post-incident analysis.

The successful exploitation of CVE-2026-33650 severely degrades the integrity and availability of the hosted video platform. An authenticated attacker with low-level moderator privileges gains the capacity to systematically dismantle the application's content library. The attacker exercises unilateral control over all video assets, regardless of the original publisher's administrative tier.

The CVSS v3.1 base score of 7.6 reflects the severity of this privilege escalation. The attack operates entirely over the network without requiring any interaction from the victim. The integrity metric is rated High due to the complete compromise of ownership metadata, while availability is rated Low to reflect the specific loss of individual video objects rather than full system downtime.

Organizations relying on AVideo for internal training, corporate communications, or monetized content distribution face significant operational disruption. The unauthorized removal of critical video assets directly impacts business continuity. Furthermore, the ability to modify metadata allows the attacker to alter video categories or titles, facilitating content defacement.