CVE-2026-88874 in AVideo
Summary
by MITRE • 09/10/2026
AVideo through revision c3edcc274c389816d434acadac07ee78eaf330c1 (master, 2026-08-23) does not enforce the Live stream password check on the stats endpoint or on the HLS origin. Live::_getStats() (plugin/Live/Live.php) returns a password-protected transmission's RTMP stream key, its isPasswordProtected flag, and its HLS (m3u8) URL to unauthenticated callers, in both the public applications list and the hidden_applications branch used when canSeeLiveFromLiveKey() fails. Separately, the shipped NGINX configuration (deploy/nginx/nginx.conf) serves the .m3u8 playlist, the AES-128 key, and the transport-stream segments from the /live location without any auth_request (the auth_key_check directive in the .key location is commented out). A remote, unauthenticated attacker can therefore retrieve the stream key and decryption key and watch a password-protected live transmission without supplying the configured password. No patched version was available at the time of the advisory.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 09/10/2026
The vulnerability identified in AVideo represents a critical authentication bypass within its live streaming infrastructure, specifically affecting revisions up to c3edcc274c389816d434acadac07ee78eaf330c1 released on August 23, 2026. This flaw stems from an improper implementation of access control mechanisms that fail to enforce password verification for sensitive endpoints related to live stream statistics and content delivery. The core technical deficiency lies in the Live::_getStats() function located within plugin/Live/Live.php, which is designed to retrieve metadata about active streams. Instead of restricting this data retrieval to authenticated users who have successfully provided valid credentials, the function returns comprehensive details including the RTMP stream key, the password protection status flag, and the HLS playlist URL for unauthenticated callers. This behavior persists regardless of whether the request originates from the public applications list or the hidden_applications branch utilized when standard visibility checks fail, indicating a systemic failure in input validation and authorization logic across multiple code paths.
The operational impact is significantly compounded by the server-side configuration provided with the software distribution. The shipped NGINX configuration file at deploy/nginx/nginx.conf serves HLS content components such as the m3u8 playlist files, AES-128 encryption keys, and transport stream segments from the /live location without implementing any authentication requests or access control directives. Notably, a directive intended to check for valid keys in the .key location is commented out by default, leaving the decryption materials publicly accessible via standard HTTP GET requests. Consequently, an attacker does not need to interact with the application logic directly to view protected content; they can simply utilize the exposed HLS URL and decrypt the stream using the retrieved AES-128 key. This architectural oversight allows for a complete circumvention of the intended password protection mechanism, effectively rendering any security controls configured at the application level obsolete due to the lack of enforcement at the web server layer.
From a threat modeling perspective, this vulnerability aligns with CWE-287 Improper Authentication and CWE-306 Missing Authentication for Critical Function within the Common Weakness Enumeration framework. The ability of an unauthenticated actor to retrieve sensitive configuration data and decryption keys facilitates unauthorized access to proprietary or restricted live broadcasts. In terms of adversarial tactics, this scenario maps directly to ATT&CK technique T1530 Data from Cloud Storage Objects, as the attacker exfiltrates encrypted media segments and their corresponding decryption materials from a cloud-hosted or web-served location without authorization. The combination of information disclosure through the API endpoint and unrestricted file serving via NGINX creates a high-severity risk where confidentiality is entirely compromised for any stream marked with password protection enabled in the administrative interface.
Mitigation strategies must address both the application logic and the server configuration to restore security boundaries. Immediately, administrators should manually edit the deploy/nginx/nginx.conf file to uncomment or implement the auth_key_check directive within the .key location block, ensuring that requests for decryption keys are validated against a secure backend service before being served. Additionally, the Live::_getStats() function requires code modification to enforce strict authentication checks prior to returning any stream metadata, particularly the RTMP key and HLS URLs. Implementing role-based access control (RBAC) ensures that only users with explicit permissions can query live statistics or manage stream configurations. Furthermore, it is advisable to deploy a Web Application Firewall rule set that monitors for anomalous requests targeting stats endpoints without valid session tokens, providing an additional layer of defense while the underlying codebase is patched in future releases.