CVE-2026-89248 in AVideo
Summary
by MITRE • 09/11/2026
AVideo through commit c3edcc274c389816d434acadac07ee78eaf330c1 is missing an authentication/authorization check in plugin/WebRTC/status.json.php. When the WebRTC plugin is present, any unauthenticated remote user can request /plugin/WebRTC/status.json.php and receive JSON containing the absolute filesystem path of the WebRTC2RTMP helper binary (revealing the document-root path), the configured WebRTC port, file_exists/is_executable status for the binary, the contents of the WebRTC log/JSON files (videos/WebRTC2RTMP.log) when present, and whether the configured port is reachable on loopback (127.0.0.1) and on the public address. The endpoint performs no User::isLogged(), User::isAdmin(), or forbiddenPage() check. The issue was unfixed at the time of reporting.
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.
Analysis
by VulDB Data Team • 09/11/2026
The vulnerability identified in AVideo, specifically within the WebRTC plugin component prior to commit c3edcc274c389816d434acadac07ee78eaf330c1, represents a critical failure in access control mechanisms. The core technical flaw lies in the endpoint /plugin/WebRTC/status.json.php, which is designed to provide operational status information about the WebRTC infrastructure but lacks any form of authentication or authorization verification. In secure software architecture, endpoints that expose internal system states must be restricted to authorized administrators or specific service accounts to prevent sensitive data leakage. However, this implementation fails to invoke standard security checks such as User::isLogged() or User::isAdmin(), nor does it utilize forbiddenPage() logic to restrict access based on user roles. Consequently, the endpoint is accessible to any unauthenticated remote actor without requiring valid credentials or session tokens, effectively bypassing the application's primary defense-in-depth strategy regarding information disclosure.
The operational impact of this vulnerability is severe due to the breadth and sensitivity of the data exposed through a simple HTTP GET request. An attacker can retrieve JSON-formatted responses that reveal the absolute filesystem path of the WebRTC2RTMP helper binary, which directly exposes the document-root path and underlying server directory structure. This information is highly valuable for subsequent exploitation phases, as it allows attackers to map the file system hierarchy and identify potential paths for local file inclusion or arbitrary file read attacks. Furthermore, the endpoint discloses the configured WebRTC port number, providing precise network topology details that facilitate targeted scanning and service enumeration. The response also includes boolean flags indicating whether specific files exist and are executable, which aids in confirming the presence of vulnerable binaries on the target system.
Beyond structural information, the vulnerability allows for significant data leakage regarding application logs and runtime states. Specifically, if log files such as videos/WebRTC2RTMP.log or associated JSON configuration files are present, their contents are returned to the unauthenticated user. These logs may contain sensitive operational details, potentially including internal IP addresses, connection timestamps, error messages that reveal stack traces, or other metadata that could aid in crafting more sophisticated attacks. Additionally, the endpoint performs network reachability checks against loopback (127.0.0.1) and public addresses for the configured port, effectively allowing an external attacker to perform a form of remote port scanning from within the application context. This capability can be used to determine if other services are running on adjacent ports or if the WebRTC service is accessible from outside the local network, thereby expanding the attack surface beyond the immediate vulnerability.
From a classification perspective, this issue aligns with CWE-200: Information Exposure and CWE-862: Missing Authorization, as it involves the unauthorized disclosure of sensitive system information due to absent access controls. In terms of the MITRE ATT&CK framework, this behavior corresponds to T1046: Network Service Discovery, where an adversary uses application functionality to map network services, and potentially T1537: Transfer Data to Cloud Account if the exposed data is exfiltrated for further analysis. The lack of authentication also touches upon CWE-287: Improper Authentication, as the system fails to verify the identity of the requester before releasing sensitive state information.
Mitigation strategies must prioritize immediate access control enforcement on the affected endpoint. Developers should implement robust authorization checks that ensure only users with administrative privileges or specific service roles can access /plugin/WebRTC/status.json.php. This typically involves integrating existing framework authentication middleware and validating user sessions against a whitelist of allowed permissions before processing any requests. Additionally, it is advisable to decouple operational status reporting from publicly accessible endpoints by moving such functionality to an internal API that requires mutual TLS authentication or token-based validation. As a temporary workaround while patches are deployed, network-level controls such as firewall rules should restrict access to the WebRTC port and related administrative interfaces to trusted IP ranges only. Regular security audits of plugin codebases are essential to ensure that new features do not introduce similar authorization gaps in future releases.