CWE-863
Allowed-with-ReviewIncorrect Authorization
Abstraction: Class · Status: Incomplete
The product performs an authorization check when an actor attempts to access a resource or perform an action, but it does not correctly perform the check.
5657 vulnerabilities reference this CWE, most recent first.
GHSA-8WGF-3MRJ-73X7
Vulnerability from github – Published: 2023-07-26 15:30 – Updated: 2023-07-31 19:01Qualys Web App Scanning Connector Plugin 2.0.10 and earlier does not correctly perform permission checks in several HTTP endpoints.
This allows attackers with global Item/Configure permission to connect to an attacker-specified URL using attacker-specified credentials IDs obtained through another method, capturing credentials stored in Jenkins.
Qualys Web App Scanning Connector Plugin 2.0.11 requires the appropriate permissions for the affected HTTP endpoints.
{
"affected": [
{
"package": {
"ecosystem": "Maven",
"name": "com.qualys.plugins:qualys-was"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "2.0.11"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2023-39154"
],
"database_specific": {
"cwe_ids": [
"CWE-863"
],
"github_reviewed": true,
"github_reviewed_at": "2023-07-26T22:37:36Z",
"nvd_published_at": "2023-07-26T14:15:10Z",
"severity": "MODERATE"
},
"details": "Qualys Web App Scanning Connector Plugin 2.0.10 and earlier does not correctly perform permission checks in several HTTP endpoints.\n\nThis allows attackers with global Item/Configure permission to connect to an attacker-specified URL using attacker-specified credentials IDs obtained through another method, capturing credentials stored in Jenkins.\n\nQualys Web App Scanning Connector Plugin 2.0.11 requires the appropriate permissions for the affected HTTP endpoints.",
"id": "GHSA-8wgf-3mrj-73x7",
"modified": "2023-07-31T19:01:10Z",
"published": "2023-07-26T15:30:57Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-39154"
},
{
"type": "WEB",
"url": "https://www.jenkins.io/security/advisory/2023-07-26/#SECURITY-3012"
},
{
"type": "WEB",
"url": "http://www.openwall.com/lists/oss-security/2023/07/26/2"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:L/I:L/A:N",
"type": "CVSS_V3"
}
],
"summary": "Incorrect permission checks in Qualys Web App Scanning Connector Plugin allow capturing credentials "
}
GHSA-8WH5-VRC5-QRVJ
Vulnerability from github – Published: 2022-05-24 19:17 – Updated: 2022-07-13 00:00IBM Sterling File Gateway 2.2.0.0 through 6.1.1.0 could allow an authenticated user to obtain sensitive information due to improper permission control. IBM X-Force ID: 186090.
{
"affected": [],
"aliases": [
"CVE-2020-4654"
],
"database_specific": {
"cwe_ids": [
"CWE-863"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2021-10-08T18:15:00Z",
"severity": "MODERATE"
},
"details": "IBM Sterling File Gateway 2.2.0.0 through 6.1.1.0 could allow an authenticated user to obtain sensitive information due to improper permission control. IBM X-Force ID: 186090.",
"id": "GHSA-8wh5-vrc5-qrvj",
"modified": "2022-07-13T00:00:51Z",
"published": "2022-05-24T19:17:01Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2020-4654"
},
{
"type": "WEB",
"url": "https://exchange.xforce.ibmcloud.com/vulnerabilities/186090"
},
{
"type": "WEB",
"url": "https://www.ibm.com/support/pages/node/6497245"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-8WJF-7PJQ-2695
Vulnerability from github – Published: 2022-05-24 17:28 – Updated: 2022-05-24 17:28A vulnerability was discovered in GitLab versions before 13.0.12, 13.1.10, 13.2.8 and 13.3.4. GitLabs EKS integration was vulnerable to a cross-account assume role attack.
{
"affected": [],
"aliases": [
"CVE-2020-13318"
],
"database_specific": {
"cwe_ids": [
"CWE-863"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2020-09-14T19:15:00Z",
"severity": "MODERATE"
},
"details": "A vulnerability was discovered in GitLab versions before 13.0.12, 13.1.10, 13.2.8 and 13.3.4. GitLabs EKS integration was vulnerable to a cross-account assume role attack.",
"id": "GHSA-8wjf-7pjq-2695",
"modified": "2022-05-24T17:28:14Z",
"published": "2022-05-24T17:28:14Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2020-13318"
},
{
"type": "WEB",
"url": "https://gitlab.com/gitlab-org/cves/-/blob/master/2020/CVE-2020-13318.json"
},
{
"type": "WEB",
"url": "https://gitlab.com/gitlab-org/gitlab/-/issues/228915"
}
],
"schema_version": "1.4.0",
"severity": []
}
GHSA-8WM7-H2QH-FF4C
Vulnerability from github – Published: 2022-05-24 17:21 – Updated: 2025-02-10 20:27Magento versions 2.3.4 and earlier, 2.2.11 and earlier (see note), 1.14.4.4 and earlier, and 1.9.4.4 and earlier have an authorization bypass vulnerability. Successful exploitation could lead to potentially unauthorized product discounts.
{
"affected": [
{
"package": {
"ecosystem": "Packagist",
"name": "magento/community-edition"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"last_affected": "2.2.11"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Packagist",
"name": "magento/community-edition"
},
"ranges": [
{
"events": [
{
"introduced": "2.3.0"
},
{
"fixed": "2.3.4-p2"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Packagist",
"name": "magento/core"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "1.9.4.5"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Packagist",
"name": "magento/project-community-edition"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"last_affected": "2.0.2"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2020-9587"
],
"database_specific": {
"cwe_ids": [
"CWE-863"
],
"github_reviewed": true,
"github_reviewed_at": "2024-01-11T16:00:40Z",
"nvd_published_at": "2020-06-26T21:15:00Z",
"severity": "HIGH"
},
"details": "Magento versions 2.3.4 and earlier, 2.2.11 and earlier (see note), 1.14.4.4 and earlier, and 1.9.4.4 and earlier have an authorization bypass vulnerability. Successful exploitation could lead to potentially unauthorized product discounts.",
"id": "GHSA-8wm7-h2qh-ff4c",
"modified": "2025-02-10T20:27:44Z",
"published": "2022-05-24T17:21:49Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2020-9587"
},
{
"type": "PACKAGE",
"url": "https://github.com/magento/magento2"
},
{
"type": "WEB",
"url": "https://helpx.adobe.com/security/products/magento/apsb20-22.html"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:N",
"type": "CVSS_V3"
}
],
"summary": "Magento authorization bypass vulnerability"
}
GHSA-8WP7-JR3V-6JG3
Vulnerability from github – Published: 2022-05-13 01:18 – Updated: 2022-05-13 01:18Warsaw Huawei Smart phones with software of versions earlier than Warsaw-AL00C00B180, versions earlier than Warsaw-TL10C01B180 have a permission control vulnerability. Due to improper authorization on specific processes, an attacker with the root privilege of a mobile Android system can exploit this vulnerability to obtain some information of the user.
{
"affected": [],
"aliases": [
"CVE-2017-8216"
],
"database_specific": {
"cwe_ids": [
"CWE-863"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2017-11-22T19:29:00Z",
"severity": "HIGH"
},
"details": "Warsaw Huawei Smart phones with software of versions earlier than Warsaw-AL00C00B180, versions earlier than Warsaw-TL10C01B180 have a permission control vulnerability. Due to improper authorization on specific processes, an attacker with the root privilege of a mobile Android system can exploit this vulnerability to obtain some information of the user.",
"id": "GHSA-8wp7-jr3v-6jg3",
"modified": "2022-05-13T01:18:23Z",
"published": "2022-05-13T01:18:23Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2017-8216"
},
{
"type": "WEB",
"url": "http://www.huawei.com/en/psirt/security-advisories/2017/huawei-sa-20170614-01-smartphone-en"
},
{
"type": "WEB",
"url": "http://www.securityfocus.com/bid/102190"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.0/AV:L/AC:L/PR:N/UI:R/S:U/C:H/I:N/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-8WPR-RJQH-X3MH
Vulnerability from github – Published: 2022-05-24 19:21 – Updated: 2022-05-24 19:21PI Vision could disclose information to a user with insufficient privileges for an AF attribute that is the child of another attribute and is configured as a Limits property.
{
"affected": [],
"aliases": [
"CVE-2021-43553"
],
"database_specific": {
"cwe_ids": [
"CWE-863"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2021-11-17T19:15:00Z",
"severity": "MODERATE"
},
"details": "PI Vision could disclose information to a user with insufficient privileges for an AF attribute that is the child of another attribute and is configured as a Limits property.",
"id": "GHSA-8wpr-rjqh-x3mh",
"modified": "2022-05-24T19:21:01Z",
"published": "2022-05-24T19:21:01Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-43553"
},
{
"type": "WEB",
"url": "https://us-cert.cisa.gov/ics/advisories/icsa-21-313-05"
}
],
"schema_version": "1.4.0",
"severity": []
}
GHSA-8WR5-X8RR-MCHX
Vulnerability from github – Published: 2022-05-24 19:19 – Updated: 2022-07-15 00:00An improper access control vulnerability in SCloudBnRReceiver in SecTelephonyProvider prior to SMR Nov-2021 Release 1 allows untrusted application to call some protected providers.
{
"affected": [],
"aliases": [
"CVE-2021-25501"
],
"database_specific": {
"cwe_ids": [
"CWE-863"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2021-11-05T03:15:00Z",
"severity": "LOW"
},
"details": "An improper access control vulnerability in SCloudBnRReceiver in SecTelephonyProvider prior to SMR Nov-2021 Release 1 allows untrusted application to call some protected providers.",
"id": "GHSA-8wr5-x8rr-mchx",
"modified": "2022-07-15T00:00:17Z",
"published": "2022-05-24T19:19:52Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-25501"
},
{
"type": "WEB",
"url": "https://security.samsungmobile.com/securityUpdate.smsb?year=2021\u0026month=11"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:L/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-8X2C-HH3C-77Q8
Vulnerability from github – Published: 2024-08-05 18:31 – Updated: 2024-08-06 18:30Insecure Permissions vulnerability in UAB Lexita PanteraCRM CMS v.401.152 and Patera CRM CMS v.402.072 allows a remote attacker to execute arbitrary code via modification of the X-Forwarded-For header component.
{
"affected": [],
"aliases": [
"CVE-2024-40530"
],
"database_specific": {
"cwe_ids": [
"CWE-863",
"CWE-94"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-08-05T16:15:36Z",
"severity": "CRITICAL"
},
"details": "Insecure Permissions vulnerability in UAB Lexita PanteraCRM CMS v.401.152 and Patera CRM CMS v.402.072 allows a remote attacker to execute arbitrary code via modification of the X-Forwarded-For header component.",
"id": "GHSA-8x2c-hh3c-77q8",
"modified": "2024-08-06T18:30:51Z",
"published": "2024-08-05T18:31:43Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-40530"
},
{
"type": "WEB",
"url": "https://critical.lt/blog/authorization-bypass-and-mass-assignment-in-pantera-crm"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-8X5V-5GH2-QR2J
Vulnerability from github – Published: 2026-07-17 03:31 – Updated: 2026-07-17 03:31OpenClaw versions 2026.5.10-beta.1 before 2026.6.5 contain an authorization bypass in the ClickClack agent-mode dispatch feature, which could ignore the toolsAllow policy check. When the affected feature is enabled and reachable, a lower-trust caller or configured input path could perform actions that should have required a stronger authorization or policy check.
{
"affected": [],
"aliases": [
"CVE-2026-62209"
],
"database_specific": {
"cwe_ids": [
"CWE-863"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-07-17T02:18:07Z",
"severity": "HIGH"
},
"details": "OpenClaw versions 2026.5.10-beta.1 before 2026.6.5 contain an authorization bypass in the ClickClack agent-mode dispatch feature, which could ignore the toolsAllow policy check. When the affected feature is enabled and reachable, a lower-trust caller or configured input path could perform actions that should have required a stronger authorization or policy check.",
"id": "GHSA-8x5v-5gh2-qr2j",
"modified": "2026-07-17T03:31:21Z",
"published": "2026-07-17T03:31:21Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/openclaw/openclaw/security/advisories/GHSA-wp73-f3gg-w4vr"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-62209"
},
{
"type": "WEB",
"url": "https://www.vulncheck.com/advisories/openclaw-beta-1-authorization-bypass-via-agent-mode-dispatch"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:N",
"type": "CVSS_V3"
},
{
"score": "CVSS:4.0/AV:N/AC:L/AT:P/PR:L/UI:N/VC:H/VI:H/VA:N/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X",
"type": "CVSS_V4"
}
]
}
GHSA-8X77-F38V-4M5J
Vulnerability from github – Published: 2026-03-25 17:49 – Updated: 2026-03-25 17:49Summary
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() ||
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.
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 free
- video_password (line 211) — change/remove password protection
- categories_id (line 168) — alter content categorization
- videoGroups (line 175) — modify user group visibility
PoC
Prerequisites: 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.
Impact
- 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.
- 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." - Access control bypass: Password-protected videos can have their passwords removed, exposing restricted content.
- Integrity loss: Video ownership records are corrupted, making audit trails unreliable.
- Availability impact: Targeted deletion of high-value content with no authorization check appropriate to the destructive action.
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.
Recommended Fix
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.
{
"affected": [
{
"package": {
"ecosystem": "Packagist",
"name": "wwbn/avideo"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"last_affected": "26.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-33650"
],
"database_specific": {
"cwe_ids": [
"CWE-863"
],
"github_reviewed": true,
"github_reviewed_at": "2026-03-25T17:49:32Z",
"nvd_published_at": "2026-03-23T19:16:41Z",
"severity": "HIGH"
},
"details": "## Summary\n\nA user with the \"Videos Moderator\" permission can escalate privileges to perform full video management operations \u2014 including ownership transfer and deletion of any video \u2014 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 __(\u0027Videos Moderator\u0027), \n __(\u0027This is a level below the (Videos Admin), this type of user can change the video publicity (Active, Inactive, Unlisted)\u0027), \n \u0027Permissions\u0027\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[\u0027id\u0027]) \u0026\u0026 !Permissions::canModerateVideos()) {\n die(\u0027{\"error\":\"2 \u0027 . __(\"Permission denied\") . \u0027\"}\u0027);\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-\u003euserCanChangeVideoOwner || Permissions::canModerateVideos() || \n Users_affiliations::isUserAffiliateOrCompanyToEachOther($obj-\u003egetUsers_id(), $_POST[\u0027users_id\u0027])) {\n $obj-\u003esetUsers_id($_POST[\u0027users_id\u0027]);\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-\u003egetUsers_id()) || $video-\u003egetUsers_id() != User::getId()){\n if (!$video-\u003euserCanManageVideo()) {\n // denied\n }\n}\n$id = $video-\u003edelete();\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 \u2014 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) \u2014 make premium content free\n- `video_password` (line 211) \u2014 change/remove password protection\n- `categories_id` (line 168) \u2014 alter content categorization\n- `videoGroups` (line 175) \u2014 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\u0027s user ID\n# TARGET_VIDEO_ID = ID of video owned by another user (e.g., admin)\ncurl -s -b cookies.txt -X POST \\\n \u0027http://localhost/objects/videoAddNew.json.php\u0027 \\\n -d \"id=TARGET_VIDEO_ID\u0026users_id=ATTACKER_USER_ID\u0026title=unchanged\"\n```\n\nExpected response: `{\"status\":true, ...}` \u2014 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 \u0027http://localhost/objects/videoDelete.json.php\u0027 \\\n -d \"id[]=TARGET_VIDEO_ID\"\n```\n\nExpected response: `{\"error\":false, ...}` \u2014 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 \u0027http://localhost/objects/videoAddNew.json.php\u0027 \\\n -d \"id=TARGET_VIDEO_ID\u0026video_password=\u0026title=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 \u2014 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 \u2014 which administrators may grant freely assuming it only allows status changes \u2014 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-\u003euserCanChangeVideoOwner || Permissions::canModerateVideos() || ...\n\n// After (fixed):\nif ($advancedCustomUser-\u003euserCanChangeVideoOwner || Permissions::canAdminVideos() || ...\n```\n\n**Fix for edit gate** (`videoAddNew.json.php:19`):\n```php\n// Before (vulnerable):\nif (!Video::canEdit($_POST[\u0027id\u0027]) \u0026\u0026 !Permissions::canModerateVideos()) {\n\n// After (fixed): \nif (!Video::canEdit($_POST[\u0027id\u0027]) \u0026\u0026 !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.",
"id": "GHSA-8x77-f38v-4m5j",
"modified": "2026-03-25T17:49:32Z",
"published": "2026-03-25T17:49:32Z",
"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"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:H/A:L",
"type": "CVSS_V3"
}
],
"summary": "AVideo: Video Moderator Privilege Escalation via Ownership Transfer Enables Arbitrary Video Deletion"
}
Mitigation
- Divide the product into anonymous, normal, privileged, and administrative areas. Reduce the attack surface by carefully mapping roles with data and functionality. Use role-based access control (RBAC) [REF-229] to enforce the roles at the appropriate boundaries.
- Note that this approach may not protect against horizontal authorization, i.e., it will not protect a user from attacking others with the same role.
Mitigation
Ensure that access control checks are performed related to the business logic. These checks may be different than the access control checks that are applied to more generic resources such as files, connections, processes, memory, and database records. For example, a database may restrict access for medical records to a specific database user, but each record might only be intended to be accessible to the patient and the patient's doctor [REF-7].
Mitigation MIT-4.4
Strategy: Libraries or Frameworks
- Use a vetted library or framework that does not allow this weakness to occur or provides constructs that make this weakness easier to avoid.
- For example, consider using authorization frameworks such as the JAAS Authorization Framework [REF-233] and the OWASP ESAPI Access Control feature [REF-45].
Mitigation
- For web applications, make sure that the access control mechanism is enforced correctly at the server side on every page. Users should not be able to access any unauthorized functionality or information by simply requesting direct access to that page.
- One way to do this is to ensure that all pages containing sensitive information are not cached, and that all such pages restrict access to requests that are accompanied by an active and authenticated session token associated with a user who has the required permissions to access that page.
Mitigation
Use the access control capabilities of your operating system and server environment and define your access control lists accordingly. Use a "default deny" policy when defining these ACLs.
No CAPEC attack patterns related to this CWE.