CVE-2026-33501: Missing Authorization Information Disclosure in WWBN AVideo Permissions Plugin

WWBN AVideo is an open-source video platform that utilizes a plugin architecture to extend base functionality. The Permissions plugin manages access control by defining relationships between user groups and various platform plugins. This system dictates which users can access specific features within the application.

In AVideo versions up to and including 26.0, a Missing Authorization vulnerability (CWE-862) exists within the Permissions plugin's administrative interface. Sibling endpoints in the plugin/Permissions/View/Users_groups_permissions/ directory, such as add.json.php and delete.json.php, properly restrict access to administrative users. The list.json.php endpoint omits this authorization gate entirely.

This oversight allows an unauthenticated remote attacker to retrieve the complete mapping of user groups to plugins. The exposed JSON matrix reveals the internal authorization model of the application. This data facilitates targeted privilege escalation attacks by exposing exactly which user groups possess access to which platform extensions.

The vulnerability originates from a failure to implement functional level access control in the list.json.php script. When an HTTP request is made to this endpoint, the PHP script initializes the global application environment by requiring configuration.php. It then proceeds directly to resource retrieval without verifying the session state or user role.

The script calls the static method Users_groups_permissions::getAll(). This method relies on the underlying ObjectYPT database abstraction layer to execute a SELECT * FROM users_groups_permissions SQL query. Because the script does not halt execution or validate the requester's privileges prior to this call, the query executes unconditionally.

The fundamental error is the absence of an explicit authorization boundary. The application relies on the developer to manually include authorization checks in every endpoint, creating a fragile security posture where a single omitted check results in direct data exposure.

Analysis of the plugin/Permissions/View/Users_groups_permissions/list.json.php file reveals the exact missing logic. The vulnerable version of the script consists of basic initialization followed immediately by data extraction.

<?php
require_once '../../../../videos/configuration.php';
require_once $global['systemRootPath'] . 'plugin/Permissions/Objects/Users_groups_permissions.php';
header('Content-Type: application/json');
$rows = Users_groups_permissions::getAll();
?>
{"data": <?php echo json_encode($rows); ?>}

The remediation applied in commit b583acdc9a9d1eab461543caa363e1a104fb4516 introduces the necessary validation. The patch first verifies that the Permissions plugin is active using AVideoPlugin::loadPluginIfEnabled('Permissions'). It then enforces the administrative requirement via User::isAdmin(), halting execution and returning an error JSON object if the check fails.

 <?php
 require_once '../../../../videos/configuration.php';
 require_once $global['systemRootPath'] . 'plugin/Permissions/Objects/Users_groups_permissions.php';
+$plugin = AVideoPlugin::loadPluginIfEnabled('Permissions');
+if (!User::isAdmin()) {
+    die(json_encode(['error' => true, 'msg' => 'You cant do this']));
+}
 header('Content-Type: application/json');
 $rows = Users_groups_permissions::getAll();

This fix aligns the list.json.php endpoint with the security model used by other administrative endpoints in the same directory, establishing a consistent authorization boundary.

Exploitation of CVE-2026-33501 requires no authentication, no special network positioning, and no prior knowledge of the target system. An attacker simply issues an HTTP GET request to the vulnerable endpoint. The vulnerability is highly reliable and leaves minimal forensic footprint beyond standard web server access logs.

The exploit can be executed using standard command-line HTTP clients. The following proof-of-concept demonstrates the attack vector:

curl -s https://<target-avideo-instance>/plugin/Permissions/View/Users_groups_permissions/list.json.php

The server responds with a JSON object containing an array of permission records. Each record links a users_groups_id to a plugins_id, alongside metadata such as type and status.

{
  "data": [
    {
      "id": "1",
      "users_groups_id": "2",
      "plugins_id": "5",
      "type": "1",
      "status": "a"
    }
  ]
}

The direct impact of CVE-2026-33501 is the unauthorized disclosure of the application's internal authorization model. The CVSS v3.1 base score of 5.3 reflects this scope, characterizing the vulnerability as a low-impact confidentiality breach with no integrity or availability consequences.

While the data exposed does not include user credentials or personally identifiable information (PII), it provides substantial reconnaissance value. By mapping user groups to specific plugins, an attacker gains a blueprint of the application's attack surface. This allows the attacker to identify which user roles possess access to potentially vulnerable extensions.

This vulnerability serves as a stepping stone for complex privilege escalation attacks. An attacker can use the permission matrix to correlate accessible plugins with known vulnerabilities in those plugins, streamlining subsequent exploitation attempts against authenticated attack surfaces.

The vendor addressed this vulnerability in March 2026. Organizations deploying WWBN AVideo must upgrade to the post-26.0 release that incorporates the official patches. The fix is implemented across two specific commits (b583acdc9a9d1eab461543caa363e1a104fb4516 and dc3c825734628bb32550d0daa125f05bacb6829c).

If immediate patching is not feasible, administrators can manually apply the patch by modifying the plugin/Permissions/View/Users_groups_permissions/list.json.php file on the server. The manual remediation involves inserting the AVideoPlugin::loadPluginIfEnabled and User::isAdmin checks directly before the header() declaration.

Network administrators can also mitigate this issue at the web application firewall (WAF) or reverse proxy level. Rules can be configured to block external requests to the plugin/Permissions/View/Users_groups_permissions/ directory, restricting access solely to trusted internal IP ranges or management subnets.