Description

WWBN AVideo through commit c3edcc274c389816d434acadac07ee78eaf330c1 fails to validate video access permissions in the videoAddViewCount.json.php endpoint before updating view statistics. Authenticated attackers can increment view counts and watch-time on videos they cannot access by submitting requests with arbitrary video IDs.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "4.3",
  "pubDate": "2026-09-12T13:16:52.640Z",
  "pubdate": "2026-09-12T13:16:52.640Z",
  "executiveSummary": "WWBN AVideo, up to and including commit c3edcc274c389816d434acadac07ee78eaf330c1, contains an improper authorization vulnerability within the videoAddViewCount.json.php endpoint.\nThe vulnerability stems from the failure to perform server-side validation of user access permissions before processing requests to update video view statistics.\nThis flaw allows authenticated attackers to artificially manipulate view counts and watch-time metrics for private or restricted videos.\nBy bypassing access controls, an attacker can influence analytics data, potentially leading to inflated popularity metrics or information disclosure regarding the existence of private content.\nExploitation requires the attacker to be authenticated to the platform; however, no administrative privileges are necessary to trigger the increment logic for arbitrary video identifiers.\nThe risk implication is primarily focused on data integrity and the potential for unauthorized interaction with restricted content metadata within the AVideo environment.",
  "technicalDetails": "The vulnerability resides in the videoAddViewCount.json.php endpoint, which is responsible for incrementing the 'view' count and 'watch-time' associated with a specific video entity in the underlying database.\nThe root cause is an insecure implementation of the input handling logic where the backend application accepts a video ID parameter from the client request without verifying if the requesting user possesses the requisite authorization to access the target video resource.\nIn the standard application flow, the server receives a POST or GET request intended to register a view event. Ideally, the application should cross-reference the user's session privileges against the permissions defined for the video ID requested.\nBecause the validation mechanism is missing or incomplete, the application processes the database update query regardless of the user's permission level. Consequently, the application trusts the provided video ID and executes the increment command in the database schema.\nAn attacker can exploit this by intercepting a legitimate request to videoAddViewCount.json.php or crafting an HTTP request containing a target 'videos_id' that corresponds to a private or otherwise restricted video.\nThe attack flow is as follows: 1) The attacker authenticates to the WWBN AVideo instance; 2) The attacker identifies or guesses the video ID of a restricted video; 3) The attacker sends a request to the vulnerable endpoint with the target video ID; 4) The server processes the request and updates the view count in the database; 5) The attacker receives a successful response, confirming the modification of the analytics data.\nThis behavior exposes the application to unauthorized metadata manipulation. While this does not directly provide the contents of the video, it allows for the subversion of internal metrics and may be used to confirm the existence of specific videos that are otherwise hidden from the user's UI.\nThe vulnerability affects all AVideo installations up to the specified commit hash, c3edcc274c389816d434acadac07ee78eaf330c1. The network exposure is limited to authenticated users; however, in environments with open registration or exposed user accounts, the barrier to exploitation is minimal."
}