CVE-2026-89249 in AVideo
Summary
by MITRE • 09/11/2026
AVideo through commit c3edcc274c389816d434acadac07ee78eaf330c1 contains a stored cross-site scripting vulnerability in the YPTWallet plugin where user-supplied CryptoWallet values are base64-encoded but not HTML-escaped before storage in wallet_log.information. Administrators viewing pending withdrawal requests in pendingRequests.php execute the stored markup in their session, allowing attackers to perform administrative actions via same-origin fetch requests.
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 09/11/2026
The vulnerability identified in AVideo through commit c3edcc274c389816d434acadac07ee78eaf330c1 represents a critical stored cross-site scripting flaw within the YPTWallet plugin, specifically affecting the handling of cryptocurrency wallet information. The core technical deficiency lies in the input validation and output encoding mechanisms employed when processing user-supplied CryptoWallet values. Although the application implements base64 encoding for these inputs prior to storage, it fails to apply HTML entity escaping before writing the data into the wallet_log.information field within the database. This architectural oversight creates a significant security gap because base64 encoding is an encoding scheme designed for binary-to-text conversion and does not provide any protection against script injection in an HTML context. Consequently, malicious payloads embedded in cryptocurrency addresses are preserved intact when retrieved from storage and rendered by the browser without sanitization.
The operational impact of this vulnerability is severe due to its stored nature and the high-privilege context required for exploitation. Attackers can inject arbitrary JavaScript code into their wallet address fields during registration or profile updates. This malicious markup persists in the database, affecting all subsequent users who view the compromised data. Specifically, administrators accessing the pendingRequests.php page to review withdrawal requests inadvertently trigger the execution of this stored script within their own browser sessions. Because the vulnerability operates within the same origin as the administrative interface, it allows for full session hijacking and privilege escalation. The attacker can leverage the administrator's active authentication cookies and security context to perform sensitive actions on behalf of the victim, such as modifying system configurations, accessing private user data, or initiating fraudulent transactions that appear legitimate due to their source from an authenticated admin session.
From a threat modeling perspective, this vulnerability aligns with CWE-79, which classifies improper neutralization of input during web page generation known as cross-site scripting. The specific mechanism here involves stored persistence rather than reflected injection, making it more dangerous as the payload is served to multiple victims over time without requiring further interaction from the attacker after initial setup. In terms of adversary tactics, this aligns with MITRE ATT&CK technique T1059, Command and Scripting Interpretation, specifically through browser-based execution via DOM manipulation or event handlers embedded in HTML attributes. The exploitation chain relies on the victim's trust in the application to correctly sanitize data before rendering it in a privileged administrative interface, highlighting a failure in defense-in-depth strategies regarding output encoding for different contexts.
To mitigate this vulnerability and prevent similar issues, developers must implement strict context-aware output encoding whenever user-supplied data is rendered into HTML documents. Base64 encoding should not be relied upon as a security control against XSS; instead, standard HTML entity escaping functions such as htmlspecialchars in PHP or equivalent secure templating engine features must be applied to ensure that special characters like angle brackets and quotes are converted to their safe textual representations before being inserted into the DOM. Additionally, implementing Content Security Policy headers can provide an additional layer of defense by restricting the sources from which scripts can be loaded and executed, thereby limiting the impact even if a bypass occurs. Regular security audits focusing on input validation pipelines and database interaction layers are essential to identify other potential instances where encoding assumptions may lead to similar exploitable conditions in web applications handling sensitive user data.