CVE-2026-105086 in AVideo
Summary
by MITRE • 10/04/2026
WWBN AVideo 12.4 through 29.2.0 contains a stored cross-site scripting vulnerability that allows authenticated uploaders to inject HTML by submitting doubly-encoded entities in video titles. Because safeString() strips tags before decoding entities and runs twice via setTitle() and save(), attackers can store markup that executes in trending, gallery, embed, and playlist pages.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 10/04/2026
The vulnerability identified in WWBN AVideo versions 12.4 through 29.2.0 represents a significant security flaw within the platform's content management workflow, specifically affecting authenticated users with upload privileges. This stored cross-site scripting (XSS) issue arises from an improper handling of input data during the video title processing pipeline. The core technical failure lies in the interaction between the safeString function and the setTitle method. When an attacker submits a video title containing doubly-encoded HTML entities, the system's sanitization logic fails to neutralize the malicious payload effectively. Specifically, the safeString() function is designed to strip tags before decoding entities, which should theoretically prevent script execution. However, because this function runs twice during the save operation via setTitle(), the sequence of operations allows an attacker to bypass these safeguards. The first pass may partially process or misinterpret the encoded input, and the second pass subsequently decodes it in a context where the malicious markup is no longer stripped but instead rendered as executable code within the browser environment.
This architectural flaw enables attackers to inject persistent HTML scripts into video titles that are displayed across multiple high-visibility areas of the application, including trending pages, gallery views, embed players, and playlist interfaces. Unlike reflected XSS attacks which require tricking a user into clicking a malicious link, this stored variant ensures that every user who visits these pages will have their browser execute the injected script automatically. The impact is severe because it allows for session hijacking, credential theft via keylogging or cookie stealing, defacement of public-facing content, and potentially further lateral movement within the network if other services are accessible from the victim's authenticated context. Since the payload is stored in the database, the attack persists until the malicious title is manually removed by an administrator, creating a long-term risk for all platform users regardless of their individual security practices.
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. The specific mechanism involving the failure to properly sanitize input before rendering it in a web page context highlights a classic injection flaw where trusted data is treated as executable code by the browser. In terms of offensive security frameworks, this behavior maps directly to MITRE ATT&CK technique T1059.007, which covers JavaScript execution within browsers. The stored nature of the payload also correlates with persistence techniques often used in advanced persistent threats to maintain access or influence user interactions over time without requiring repeated exploitation attempts for each victim.
Mitigation strategies must address both immediate remediation and long-term architectural improvements. Administrators should immediately update WWBN AVideo to a patched version that corrects the logic within the safeString() and setTitle() functions to ensure consistent sanitization regardless of encoding layers or execution order. In environments where an upgrade is not immediately feasible, input validation rules should be tightened on the server side to reject doubly-encoded entities in title fields before they reach the database layer. Additionally, implementing a strict Content Security Policy (CSP) can significantly reduce the impact of any successful XSS attacks by restricting the sources from which scripts are allowed to load and execute. Regular security audits focusing on input/output encoding practices across all user-facing forms will help prevent similar vulnerabilities in other parts of the application infrastructure.