CVE-2026-88866 in AVideo
Summary
by MITRE • 09/10/2026
WWBN AVideo through commit c3edcc274c389816d434acadac07ee78eaf330c1 contains a stored cross-site scripting vulnerability in the LoginControl plugin that fails to encode the User-Agent header before storing it in login history. Attackers with any valid login account can inject malicious scripts in the User-Agent header that execute in administrator browsers when viewing the Login History page, allowing script execution within the administrator session.
Be aware that VulDB is the high quality source for vulnerability data.
Analysis
by VulDB Data Team • 09/10/2026
The vulnerability identified in WWBN AVideo through commit c3edcc274c389816d434acadac07ee78eaf330c1 represents a significant security flaw rooted in improper input validation and output encoding within the LoginControl plugin. This specific issue is classified as a stored cross-site scripting vulnerability, which falls under CWE-79: Improper Neutralization of Input During Web Page Generation. The core technical failure lies in the application's handling of HTTP headers during the authentication process. Specifically, when a user logs into the system, the server captures and stores the User-Agent header associated with that login attempt to maintain a history of access events. However, the implementation fails to apply proper encoding or sanitization routines to this data before persisting it in the database. This oversight allows an attacker who possesses valid credentials for any standard user account to inject malicious JavaScript payloads directly into the stored record by manipulating their User-Agent string during the login request.
The operational impact of this vulnerability is severe due to its persistence and the high privilege level required to view the affected data. Unlike reflected XSS, where the payload must be executed immediately via a crafted link, stored XSS persists on the server side until manually removed or expired. In this scenario, when an administrator accesses the Login History page to review past authentication events, the browser retrieves the unencoded malicious script from the database and renders it within the context of the administrative interface. Because the code executes in the admin's browser session, it inherits the same privileges as that session. This allows the attacker to perform actions on behalf of the administrator, such as modifying system configurations, accessing sensitive user data, creating new privileged accounts, or defacing the application interface. The requirement for a valid login account means this is an authenticated attack vector, which significantly lowers the barrier to entry compared to unauthenticated exploits but remains highly dangerous given that obtaining legitimate credentials is often feasible through phishing or credential stuffing attacks.
From a threat intelligence perspective, this vulnerability aligns with MITRE ATT&CK technique T1059: Command and Scripting Interpreter, specifically under sub-techniques involving JavaScript execution within web browsers. The attack chain begins with initial access via valid credentials (T1078), followed by the injection of malicious content into a stored field (CWE-20). Upon viewing the history page, the script executes in the context of an elevated privilege account, facilitating lateral movement or further exploitation depending on the application's architecture. The persistence mechanism ensures that every time an administrator views the login logs, they are potentially compromised, creating a continuous risk vector rather than a one-time event.
Mitigation strategies must address both immediate remediation and long-term defensive coding practices. The primary fix involves implementing strict output encoding for all data rendered in HTML contexts, particularly when displaying user-supplied input such as headers stored from previous requests. Developers should utilize context-aware escaping functions provided by modern web frameworks to ensure that special characters like angle brackets, quotes, and ampersands are neutralized before being written to the DOM or database. Additionally, implementing a Content Security Policy (CSP) can provide an additional layer of defense by restricting the sources from which scripts can be loaded and executed, thereby mitigating the impact even if input validation fails. Regular security audits focusing on header handling and login history modules are recommended to identify similar oversights in other parts of the application architecture.