Description

AVideo through commit c3edcc274c389816d434acadac07ee78eaf330c1 fails to verify ownership in addLiveLink.php when updating LiveLinks, allowing authenticated users to modify other users' links. A canStream user can overwrite another user's LiveLink HLS source and metadata by supplying an existing linkId, redirecting viewers to attacker-controlled media.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "6.5",
  "pubDate": "2026-09-11T12:16:55.377Z",
  "pubdate": "2026-09-11T12:16:55.377Z",
  "executiveSummary": "This vulnerability is an Insecure Direct Object Reference (IDOR) within the AVideo platform, specifically located in the addLiveLink.php script. The flaw allows an authenticated user with 'canStream' privileges to perform unauthorized modifications to live links belonging to other users.\nBy manipulating the linkId parameter, a malicious actor can overwrite existing HLS source configurations and associated metadata. This results in a complete compromise of the affected live stream's integrity, enabling the redirection of legitimate traffic to arbitrary, attacker-controlled media sources.\nThe vulnerability affects AVideo through commit c3edcc274c389816d434acadac07ee78eaf330c1. The risk implication is significant as it facilitates unauthorized content replacement, potential phishing, or the distribution of malicious content under the guise of legitimate user streams. Exploitation requires an authenticated account with at least 'canStream' privileges but does not require administrative access, making it a critical concern for multi-tenant AVideo deployments.",
  "technicalDetails": "The root cause of this vulnerability is the absence of server-side authorization checks within the 'addLiveLink.php' file when processing update requests for existing LiveLinks. In the AVideo architecture, the application logic assumes that any user possessing the 'canStream' capability is authorized to modify any link record provided in the HTTP request without validating the record's ownership against the session-authenticated user ID.\nThe exploitation flow begins when an attacker, authenticated with 'canStream' permissions, initiates a request to the 'addLiveLink.php' endpoint. Typically, this endpoint is intended to create or update live stream configurations. The attacker identifies or enumerates a target 'linkId' belonging to another user. By submitting a crafted POST or GET request that includes this specific 'linkId' alongside modified parameters (such as the HLS source URL and metadata fields), the attacker triggers the update function.\nBecause the server-side code fails to perform a query to verify if the 'linkId' belongs to the current user (e.g., 'SELECT * FROM live_links WHERE id = ? AND user_id = ?'), the database performs an UPDATE operation on the record corresponding to the attacker-supplied ID. This overwrites the legitimate data with the attacker's payload. Consequently, the HLS manifest URL is redirected to the attacker's server, and any metadata associated with the stream is replaced.\nThe impact is a successful account-level takeover of the live stream object. When end-users or viewers attempt to access the victim's live stream via the original link, the AVideo backend serves the attacker's manipulated HLS manifest. This allows for the injection of arbitrary, potentially malicious, or unauthorized multimedia content into the victim's channel. The vulnerability persists until the victim or an administrator manually corrects the configuration. The lack of strict access control lists (ACLs) or ownership verification logic at the object level in the 'addLiveLink.php' script remains the primary failure point in the application's security model."
}