Description

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.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "5.4",
  "pubDate": "2026-09-11T12:16:56.160Z",
  "pubdate": "2026-09-11T12:16:56.160Z",
  "executiveSummary": "AVideo through version 29.0 is susceptible to an Insecure Direct Object Reference (IDOR) vulnerability within the 'objects/categoryDeleteAssets.json.php' endpoint. The flaw allows authenticated, non-privileged users to trigger the recursive deletion of arbitrary category asset directories located on the server filesystem.\nThe vulnerability exists due to inadequate authorization checks during the deletion process. Specifically, the affected component fails to verify user ownership of the targeted category, instead relying solely on a CSRF nonce and a general capability check ('canCreateCategory').\nOn instances where the 'usersCanCreateNewCategories' configuration is enabled, an attacker with the 'canUpload' capability can delete icons and images associated with any category by manipulating the 'id' parameter in a POST request. While the vulnerability does not result in remote code execution or direct database record deletion, it poses a significant risk to the integrity of the application's visual assets and content management structure.\nSuccessful exploitation allows unauthorized destruction of site data, leading to service degradation and administrative overhead for restoration. As no patch is currently available, the risk remains present for all installations where the vulnerable configuration is active.",
  "technicalDetails": "The vulnerability resides in the backend processing script 'objects/categoryDeleteAssets.json.php'. The application logic performs a validation check using 'Category::canCreateCategory()' and verifies a CSRF nonce; however, it fails to implement the necessary 'Category::userCanEditCategory()' ownership check that is standard in other deletion functions, such as 'Category::delete()'.\nThe attack vector involves a POST request targeting the 'objects/categoryDeleteAssets.json.php' endpoint. An authenticated user possessing the 'canUpload' capability and the ability to create categories can supply an arbitrary integer value via the '$_REQUEST['id']' parameter. Because the application processes this input without verifying if the authenticated user owns or is authorized to modify the specified category, the backend function 'Category::deleteAssets()' is invoked with the user-supplied identifier.\nUpon invocation, 'Category::deleteAssets()' performs a recursive filesystem deletion on the directory path '{systemRootPath}videos/categories/assets/{id}/'. This effectively wipes all assets, icons, and images associated with the provided category ID. The attack flow is as follows: 1) The attacker authenticates to an AVideo instance where 'usersCanCreateNewCategories' is enabled. 2) The attacker identifies a target category ID they do not own. 3) The attacker crafts a POST request to 'objects/categoryDeleteAssets.json.php' with the 'id' parameter set to the target identifier. 4) The server validates the CSRF token and the attacker's 'canCreateCategory' capability, but skips the ownership validation. 5) The application executes the recursive 'rm' equivalent on the target asset directory, resulting in unauthorized data loss.\nThis IDOR flaw highlights a lack of 'Authorization' enforcement at the controller layer. By failing to validate the relationship between the session user and the object ID, the application permits horizontal privilege escalation in the context of file deletion. While the database records for the category and associated videos remain intact, the loss of visual assets impacts the frontend representation and can lead to broken UI elements or disrupted administrative workflows. The vulnerability affects AVideo through version 29.0 and is considered a high-risk misconfiguration in environments where non-admin users have elevated upload capabilities."
}