CVE-2026-92584 in AVideo
Summary
by MITRE • 09/17/2026
AVideo through 29.0 (current revision e01e41ecc) contains a stored cross-site scripting vulnerability. The unauthenticated view-counter endpoint objects/videoAddViewCount.json.php reaches VideoStatistic::save(), which writes the caller's User-Agent (via getUserAgentInfo(), which returns unrecognized agent strings verbatim) directly into the `app` column of the videos_statistics table without invoking the sanitizing setter setApp(); normalizeApp() only truncates the value to 45 characters. The video owner's and administrator's statistics page (view/videoViewsInfo.php) renders this field in a DataTables 1.12.1 column with an unescaped renderer, and DataTables assigns cell content using innerHTML, so attacker-supplied HTML is parsed and executed in the privileged user's authenticated session when the statistics page is viewed. No patched version was available at the time of the advisory.
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.
Analysis
by VulDB Data Team • 09/17/2026
The vulnerability identified in AVideo versions up to 29.0 represents a critical stored cross-site scripting flaw located within the video statistics management subsystem. This security defect arises from an improper interaction between the unauthenticated view-counting endpoint and the backend database storage mechanism, specifically involving the VideoStatistic::save() method. The root cause lies in the handling of the User-Agent header string provided by clients requesting to increment a video's view count via the objects/videoAddViewCount.json.php endpoint. Instead of sanitizing or validating this input before persistence, the system invokes getUserAgentInfo(), which returns unrecognized agent strings verbatim without any encoding or filtering. This unsanitized data is then written directly into the app column of the videos_statistics table in the database.
The technical flaw is compounded by a deficiency in the application's validation logic. While there exists a setter method named setApp() intended to handle sanitization, it is bypassed during this specific code path. Furthermore, an auxiliary function normalizeApp(), which might be expected to provide some level of protection, only performs string truncation limited to forty-five characters. This length restriction fails to mitigate the risk because many malicious payloads, including simple script tags or event handlers, can execute successfully within such a short character limit when rendered in a browser context that interprets HTML content as executable code rather than plain text.
The operational impact of this vulnerability is severe due to its stored nature and the privilege level required for exploitation. When an attacker crafts a malicious User-Agent string containing JavaScript payload, it becomes permanently stored in the database associated with specific video statistics records. The danger materializes when users with elevated privileges, such as video owners or system administrators, access the view/videoViewsInfo.php page to review these statistics. This interface utilizes DataTables version 1.12.1 for rendering tabular data. Crucially, the renderer used in this context does not escape HTML entities before assigning content to table cells. Since DataTables assigns cell content using innerHTML by default, any HTML or JavaScript contained within the stored User-Agent string is parsed and executed directly within the authenticated session of the privileged user.
This execution environment allows for a wide range of malicious activities beyond simple script injection. An attacker can steal administrative cookies or session tokens to hijack accounts, perform actions on behalf of the administrator such as modifying system configurations or deleting content, or redirect users to phishing sites designed to harvest credentials. The lack of output encoding in the DataTables renderer effectively turns every view count increment into a potential vector for persistent compromise of high-privilege accounts within the AVideo ecosystem.
From a classification perspective, this vulnerability aligns with CWE-79, which describes Improper Neutralization of Input During Web Page Generation commonly known as Cross-site Scripting (XSS). Specifically, it falls under stored XSS where malicious scripts are permanently stored on target servers and delivered to users when they request information from the server. In terms of offensive security frameworks, this attack vector maps to MITRE ATT&CK technique T1059.007, which covers JavaScript execution within a browser environment, often used for credential access or lateral movement after initial compromise via social engineering or automated scanning.
Mitigation strategies must address both the input validation and output encoding aspects of the vulnerability. Since no patched version was available at the time of the advisory, administrators should implement immediate compensating controls. The most effective short-term fix involves modifying the source code to ensure that all data written to the videos_statistics table is properly sanitized using a robust whitelisting approach or strict HTML entity encoding before storage. Additionally, developers must update the DataTables configuration in view/videoViewsInfo.php to explicitly escape output when rendering cell content, ensuring that innerHTML is not used for untrusted data sources. Until code patches are applied, restricting access to the statistics pages and monitoring logs for anomalous User-Agent strings containing script-like patterns can help reduce exposure risk.