GHSA-8x77-f38v-4m5j

Summary

A user with the "Videos Moderator" permission can escalate privileges to perform full video management operations — including ownership transfer and deletion of any video — despite the permission being documented as only allowing video publicity changes (Active, Inactive, Unlisted). The root cause is that Permissions::canModerateVideos() is used as an authorization gate for full video editing in videoAddNew.json.php, while videoDelete.json.php only checks ownership, creating an asymmetric authorization boundary exploitable via a two-step ownership-transfer-then-delete chain.

Details

The PERMISSION_INACTIVATEVIDEOS (ID 11) permission is described as a limited moderator role in plugin/Permissions/Permissions.php:213:

$permissions[] = new PluginPermissionOption(
    Permissions::PERMISSION_INACTIVATEVIDEOS, 
    __('Videos Moderator'), 
    __('This is a level below the (Videos Admin), this type of user can change the video publicity (Active, Inactive, Unlisted)'), 
    'Permissions'
);

However, Permissions::canModerateVideos() (Permissions.php:175) is reused as an authorization gate in multiple locations in videoAddNew.json.php that go far beyond status changes:

1. Upload gate bypass (videoAddNew.json.php:10): User::canUpload() (user.php:2650) returns true if Permissions::canModerateVideos() is true, granting moderators upload access.

2. Edit gate bypass (videoAddNew.json.php:19):

if (!Video::canEdit($_POST['id']) && !Permissions::canModerateVideos()) {
    die('{"error":"2 ' . __("Permission denied") . '"}');
}

Video::canEdit() correctly checks only canAdminVideos() and ownership, but the || !Permissions::canModerateVideos() fallback allows moderators to edit any video.

3. Ownership transfer (videoAddNew.json.php:222):

if ($advancedCustomUser->userCanChangeVideoOwner || Permissions::canModerateVideos() ||...