CVE-2026-34247: Insecure Direct Object Reference and Information Disclosure in WWBN AVideo

WWBN AVideo is an open-source video platform that allows users to host and manage video content, including live streaming capabilities. The platform utilizes various plugins to extend its functionality. The Live plugin, responsible for managing scheduled broadcasts, exposes an endpoint at plugin/Live/uploadPoster.php for users to upload custom poster images for their upcoming live streams.

An architectural flaw exists in the authorization model of this endpoint, classified under CWE-862 (Missing Authorization). The application correctly verifies that the user making the request possesses a valid session, but it fails to verify that the authenticated user owns the specific resource they are attempting to modify. This failure creates an Insecure Direct Object Reference (IDOR) vulnerability.

Exploitation of this vulnerability produces a dual-impact scenario. The primary mechanism allows an attacker to overwrite the visual assets of any scheduled stream by manipulating a single integer parameter. The secondary mechanism is an information disclosure triggered by the application's internal event system. Upon successfully processing the malicious file upload, the application broadcasts an unsecured notification containing highly sensitive credentials belonging to the victim.

The vulnerability originates in the input processing and authorization phases of the plugin/Live/uploadPoster.php script. When a user submits a poster upload request, the application retrieves the live_schedule_id and live_servers_id parameters directly from the $_REQUEST array using the intval() function. This initial processing sanitizes the input to ensure it is an integer, but it performs no validation regarding the relationship between the requesting user and the provided schedule ID.

The script subsequently calls the User::isLogged() method. This function confirms the presence of a valid authentication token, satisfying the requirement that the user is logged into the system. However, the script terminates its authorization checks at this stage. It proceeds to utilize the unvalidated $live_schedule_id to construct the file path for the target poster image. The application executes a move_uploaded_file operation against this path, directly overwriting the existing asset associated with the targeted schedule ID.

The critical information disclosure occurs in the post-upload execution flow. After successfully moving the file, the script instantiates a Live_schedule object corresponding to the modified ID. It then invokes the Live::notifySocketStats method. This method generates a socketLiveOFFCallback message intended to update client interfaces. The application broadcasts this payload over WebSockets to all connected clients. The payload inherently includes the state data of the modified schedule, which exposes the users_id and the private broadcast key of the schedule's owner.

This behavior highlights an inconsistency within the application's internal security posture. Other components within the AVideo platform correctly implement resource ownership validation. Endpoints such as plugin/Live/uploadPoster.json.php properly restrict access by requiring the user to be an administrator or the explicit owner of the object, indicating that the vulnerability in uploadPoster.php is an isolated implementation oversight rather than a systemic design flaw.

The vulnerable implementation relies exclusively on global authentication state without contextual authorization. The initial logic simply verifies if the session is active before proceeding with file operations.

$live_servers_id = intval($_REQUEST['live_servers_id']);
$live_schedule_id = intval($_REQUEST['live_schedule_id']);
 
if (!User::isLogged()) {
    $obj->msg = 'You cant edit this file';
    die(json_encode($obj));
}

The vendor addressed this flaw in commit 5fcb3bdf59f26d65e203cfbc8a685356ba300b60. The patch introduces a precise contextual authorization check immediately following the global session verification. The patched code instantiates the target object and compares the owner's ID against the current session ID.

--- a/plugin/Live/uploadPoster.php
+++ b/plugin/Live/uploadPoster.php
@@ -16,6 +16,14 @@
     die(json_encode($obj));
 }
 
+if (!empty($live_schedule_id)) {
+    $ls = new Live_schedule($live_schedule_id);
+    if (!User::isAdmin() && $ls->getUsers_id() != User::getId()) {
+        $obj->msg = 'You cant edit this file';
+        die(json_encode($obj));
+    }
+}
+
 $live = AVideoPlugin::loadPluginIfEnabled("Live");

This remediation ensures that the live_schedule_id parameter cannot be manipulated to access unowned resources. The application first checks if the parameter is provided. If it is, the code initializes a Live_schedule object and retrieves the identifier of the legitimate owner via $ls->getUsers_id(). The logic then enforces a strict condition: unless the requesting user possesses administrative privileges (User::isAdmin()), their user ID (User::getId()) must exactly match the owner's ID. Requests failing this condition are terminated immediately.

Exploitation requires the attacker to possess a low-privileged account on the target AVideo instance. The attack methodology consists of three distinct phases: authentication, payload delivery via IDOR, and data extraction via WebSocket monitoring.

In the authentication phase, the attacker authenticates with the platform to obtain a valid session cookie. This satisfies the User::isLogged() check within the target script. The attacker then targets a known or enumerable live_schedule_id belonging to the victim. Since the schedule IDs are sequential integers, they are highly susceptible to simple enumeration.

The attacker constructs a multipart/form-data POST request directed at /plugin/Live/uploadPoster.php. The request includes a benign or malicious image file, the targeted live_schedule_id, and a live_servers_id value (typically 0).

curl -b cookies.txt \
  -F 'file_data=@malicious_poster.jpg' \
  -F 'live_schedule_id=1' \
  -F 'live_servers_id=0' \
  'https://target-avideo.com/plugin/Live/uploadPoster.php'

Simultaneously, the attacker monitors the application's WebSocket communications. Upon successful processing of the payload, the server triggers the Live::notifySocketStats routine. The attacker observes the incoming socketLiveOFFCallback message, which contains the victim's internal user ID and private broadcast key.

{
  "key": "VICTIM_PRIVATE_BROADCAST_KEY",
  "users_id": 123,
  "stats": { ... }
}

The vulnerability introduces a complex security impact combining integrity loss and severe confidentiality breach. The primary mechanism constitutes a low-level integrity violation. By overwriting scheduled stream posters, an attacker can deface the platform, display inappropriate content, or conduct social engineering campaigns against viewers expecting legitimate broadcast material.

The secondary mechanism poses a significantly higher operational risk. The exposure of the private broadcast key via the global WebSocket broadcast completely compromises the security boundary of the victim's live stream. The broadcast key operates as a direct authentication token for the streaming ingest server (such as RTMP).

Possession of this key allows an attacker to hijack the victim's stream entirely. The attacker can push arbitrary video feeds to the ingest server under the victim's identity. If the attacker initiates their broadcast before the legitimate owner, they can effectively deny service to the victim, as the streaming server will reject the legitimate owner's subsequent connection attempts.

The CVSS v3.1 vector is CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:N, resulting in a base score of 5.4 (Medium). The Confidentiality impact is rated Low in the standardized vector because the vulnerability leaks specific credentials rather than providing systemic read access. However, within the context of the platform's core streaming functionality, the operational severity of this credential disclosure is substantial.

The vendor has addressed this vulnerability in versions of WWBN AVideo released subsequent to version 26.0. System administrators must prioritize upgrading their AVideo installations to version 26.1 or the latest available stable release. The official patch introduces proper authorization checks that explicitly validate resource ownership before permitting modifications.

In environments where immediate upgrading is structurally prohibitive, administrators can apply the patch manually. This involves editing the plugin/Live/uploadPoster.php file and inserting the Live_schedule authorization logic directly below the existing User::isLogged() check. The requisite code snippet is available in the official commit diff 5fcb3bdf59f26d65e203cfbc8a685356ba300b60.

Security teams should implement specific monitoring rules to detect exploitation attempts. Web application firewalls and access logs should be configured to flag anomalous HTTP POST requests targeting /plugin/Live/uploadPoster.php. A high frequency of requests from a single authenticated session referencing varying live_schedule_id parameters serves as a strong indicator of enumeration and exploitation activity.