CVE-2026-86188 in AVideo
Summary
by MITRE • 09/05/2026
AVideo with YPTSocket plugin enabled contains a cross-site scripting vulnerability allowing unauthenticated attackers to execute arbitrary JavaScript in other users' browsers via the websocket callback mechanism. Attackers can send crafted socket messages with callback names resolving to global functions like avideoConfirmHTML that accept untrusted data and assign it to innerHTML, achieving script execution in the victim's origin without authentication or user interaction.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 09/05/2026
The vulnerability identified within AVideo stems from a critical implementation flaw in its YPTSocket plugin, specifically involving the handling of WebSocket callback mechanisms. This cross-site scripting (XSS) issue allows unauthenticated attackers to execute arbitrary JavaScript code within the context of other users' browsers. The root cause lies in how the application processes incoming socket messages and maps them to specific global functions for execution. When a client connects via WebSocket, it can specify a callback function name that the server will invoke upon receiving certain events or data. In this flawed implementation, the system fails to adequately sanitize or validate these callback names against a strict allowlist of safe operations. Instead, it dynamically resolves the provided string as a global JavaScript variable and invokes it with user-supplied arguments passed through the WebSocket message payload.
The technical mechanism exploits the fact that certain global functions in the AVideo application environment are designed to accept untrusted data and render it directly into the Document Object Model (DOM). Specifically, the function avideoConfirmHTML is cited as a primary vector for this exploitation. This function takes input parameters and assigns them to the innerHTML property of an element on the page. Because modern web browsers interpret content assigned to innerHTML as executable HTML and JavaScript if not properly escaped or encoded, any script tags or event handlers embedded within the payload will be executed by the victim's browser. Since this process occurs via a WebSocket connection which is typically established after initial page load but does not require re-authentication for every message in many configurations, an attacker can inject malicious payloads without needing valid session credentials or triggering user interaction such as clicking a link.
From an operational impact perspective, this vulnerability poses severe risks to the confidentiality, integrity, and availability of the AVideo platform and its users. Successful exploitation allows attackers to perform actions on behalf of authenticated victims, including stealing sensitive cookies, session tokens, or personal data displayed in the browser context. It also enables phishing attacks where malicious content is injected into legitimate pages, potentially leading to credential harvesting from unsuspecting users. Furthermore, persistent XSS stored via this vector could affect multiple users over time if the input is saved and later rendered by other visitors. The lack of authentication requirements makes this vulnerability particularly dangerous as it can be exploited remotely against any visitor who has loaded a page utilizing the vulnerable WebSocket functionality, significantly expanding the attack surface beyond just logged-in administrators or content creators.
This flaw aligns with CWE-79, which describes Improper Neutralization of Input During Web Page Generation commonly known as Cross-site Scripting (XSS). Specifically, it represents an XSS via DOM-based vector where the vulnerability exists in client-side code that processes data from a WebSocket source without proper validation. In terms of offensive security frameworks, this technique corresponds to ATT&CK T1059.007, which covers JavaScript execution on web browsers, and potentially T1189 if used for initial access or drive-by compromise scenarios. The exploitation relies on the browser's default behavior of executing scripts embedded in HTML content rendered via innerHTML assignments, a common pitfall when dynamic content injection is not carefully controlled.
Mitigation strategies must focus on strict input validation and output encoding principles applied at both the server-side WebSocket handler and client-side JavaScript logic. First, implement a rigorous allowlist for all callback function names accepted by the YPTSocket plugin; only predefined, safe functions should be resolvable from incoming socket messages. Second, avoid using innerHTML or similar DOM manipulation methods that interpret raw strings as HTML when dealing with untrusted data. Instead, use textContent to insert plain text or employ robust templating engines that automatically escape special characters before rendering content into the DOM. Additionally, enforce Content Security Policy (CSP) headers that restrict script execution sources and prevent inline scripts where possible, adding a layer of defense-in-depth even if code-level fixes are delayed. Regular security audits focusing on dynamic function invocation patterns in WebSocket handlers will help identify similar vulnerabilities across other plugins or modules within the AVideo ecosystem.