CVE-2026-89257 in AVideo
Summary
by MITRE • 09/11/2026
AVideo through 29.0 contains an insecure direct object reference (IDOR) vulnerability in objects/categoryDeleteAssets.json.php. The endpoint validates only the Category::canCreateCategory() capability and a CSRF nonce before passing the attacker-supplied $_REQUEST['id'] to Category::deleteAssets(), which recursively removes {systemRootPath}videos/categories/assets/{id}/. It omits the Category::userCanEditCategory() ownership check enforced by the sibling Category::delete(). On installations where the non-default usersCanCreateNewCategories setting is enabled, an authenticated non-admin user with the canUpload capability can send a POST request with an arbitrary category ID and recursively delete any category's on-disk asset directory (icons/images). Category records and videos are not deleted. As of the advisory publication no patched version was available.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 09/11/2026
The vulnerability identified in AVideo versions up to 29.0 represents a critical insecure direct object reference flaw located within the endpoint objects/categoryDeleteAssets.json.php. This specific component is responsible for handling requests to remove asset files associated with video categories, such as icons and images stored on disk. The core technical deficiency lies in an inconsistent implementation of access control checks during the deletion process. When processing a POST request containing an arbitrary category identifier via the $_REQUEST['id'] parameter, the script performs validation by checking only two conditions: whether the authenticated user possesses the canCreateCategory capability and whether a valid CSRF nonce is provided. Crucially, it fails to verify if the requesting user has ownership or editing rights over the specific target category. This oversight stands in stark contrast to the sibling Category::delete() method, which correctly enforces the Category::userCanEditCategory() check before proceeding with any destructive operations.
This architectural inconsistency allows an authenticated non-administrator user who holds the canUpload capability to exploit this gap by supplying a category ID that does not belong to them. Upon successful authentication and CSRF validation, the application proceeds to invoke Category::deleteAssets(), which recursively traverses and deletes all files within the directory path {systemRootPath}videos/categories/assets/{id}/. The operational impact of this vulnerability is significant for environments where the usersCanCreateNewCategories setting is enabled, as it expands the attack surface beyond default configurations. An attacker can effectively cause a denial of service by destroying visual assets such as category thumbnails and icons, thereby degrading the user experience and potentially breaking frontend displays that rely on these resources. However, it is important to note that this vulnerability does not result in data loss at the database level; video records and metadata remain intact because only the file system assets are targeted for deletion.
From a classification perspective, this flaw aligns with CWE-284, which describes Improper Access Control, specifically manifesting as an Insecure Direct Object Reference where object identifiers are used to access resources without sufficient authorization checks. The attack vector is categorized under MITRE ATT&CK technique T1078, Valid Accounts, as it requires prior authentication but leverages insufficient privilege separation between different administrative functions within the same user role. Since no patched version was available at the time of advisory publication, immediate mitigation strategies must be implemented manually by system administrators and developers. The primary remediation involves modifying the source code for objects/categoryDeleteAssets.json.php to include a rigorous ownership verification step similar to that found in Category::delete(). Specifically, the application should call Category::userCanEditCategory() or an equivalent check against the target category ID before executing any file deletion logic. Additionally, implementing strict input validation and ensuring that all destructive API endpoints adhere to consistent authorization policies will prevent recurrence of this class of vulnerability across other parts of the platform.