WWBN AVideo CVE-2026-89248

Exploitation requires that the AVideo WebRTC plugin be installed and present on the target server - instances without this plugin do not expose the vulnerable endpoint. Given those conditions, no authentication or special configuration is needed: any network-reachable AVideo instance with the WebRTC plugin enabled is vulnerable to an unauthenticated GET request. Limiting factors are the plugin prerequisite and the fact that impact is information disclosure only - no direct code execution, data modification, or denial of service results from this endpoint alone.

The CVSS 4.0 score of 6.9 (AV:N/AC:L/AT:N/PR:N/UI:N/VC:L) accurately reflects a network-reachable, unauthenticated information-disclosure flaw with limited direct confidentiality impact - no credentials or private media content are exposed. Real-world risk is moderate rather than critical: the primary value to an attacker is reconnaissance (document root path, binary layout, open port confirmation) that enables more precise follow-on exploitation, not immediate compromise. No public exploit code has been identified at the time of analysis, and the vulnerability is not listed in the CISA KEV catalog. EPSS data is not present in the source intelligence, so exploitation probability cannot be quantified; however, the simplicity of a single unauthenticated GET request means that even a mid-sized municipal IT team in radom running a public AVideo instance with the WebRTC plugin enabled should treat remediation as a near-term priority, given that the leaked path information concretely lowers the bar for directory traversal or file-inclusion attacks. The condition that the WebRTC plugin must be present meaningfully scopes exposure to a subset of AVideo deployments.

An attacker sends a single unauthenticated HTTP GET request to https://target.example.com/plugin/WebRTC/status.json.php on any publicly accessible AVideo instance with the WebRTC plugin installed. The server responds with a JSON payload containing the absolute document-root path (e.g., /var/www/html/avideo), the WebRTC service port, and log file contents - information the attacker uses to refine path-traversal or local-file-inclusion payloads in subsequent requests. No exploit code is publicly known, but the trivial nature of the request means any HTTP client suffices.