CVE-2026-34375: Wwbn Avideo XSS Vulnerability

CVE-2026-34375 Overview

A reflected Cross-Site Scripting (XSS) vulnerability exists in WWBN AVideo, an open source video platform. In versions up to and including 26.0, the YPTWallet Stripe payment confirmation page directly echoes the $_REQUEST['plugin'] parameter into a JavaScript block without any encoding or sanitization. The plugin parameter is not included in any of the framework's input filter lists defined in security.php, allowing malicious input to pass through completely raw.

Critical Impact

An attacker can inject arbitrary JavaScript via a crafted malicious URL. The vulnerable script block also outputs the current user's username and password hash via User::getUserName() and User::getUserPass(), meaning successful XSS exploitation can immediately exfiltrate user credentials.

Affected Products

• WWBN AVideo versions up to and including 26.0
• YPTWallet Stripe payment confirmation functionality
• Self-hosted AVideo installations using the Stripe payment plugin

Discovery Timeline

• 2026-03-27 - CVE-2026-34375 published to NVD
• 2026-03-31 - Last updated in NVD database

Technical Details for CVE-2026-34375

Vulnerability Analysis

This reflected XSS vulnerability stems from improper handling of user-supplied input in the YPTWallet Stripe payment confirmation page. The $_REQUEST['plugin'] parameter is directly embedded into a JavaScript execution context without any output encoding, HTML entity escaping, or input validation. What makes this vulnerability particularly dangerous is the presence of sensitive user data within the same script block—specifically the user's username and password hash retrieved via User::getUserName() and User::getUserPass() method calls.

The lack of input filtering occurs because the plugin parameter was not added to the framework's security filter definitions in security.php. This oversight allows attackers to break out of the JavaScript context and inject arbitrary code that executes in the victim's browser session with full access to the DOM, cookies, and the exposed credentials.

Root Cause

The root cause is insufficient input validation and missing output encoding for the plugin request parameter. The AVideo framework maintains security filter lists in security.php that sanitize request parameters, but the plugin parameter was inadvertently omitted from these lists. Combined with the direct echo of user input into a JavaScript context and the exposure of sensitive credential data within the same code block, this creates a high-severity security flaw.

Attack Vector

The attack is network-based and requires user interaction. An attacker crafts a malicious URL containing JavaScript payload in the plugin parameter and tricks a victim into clicking it (via phishing, social engineering, or embedding the link). When the victim visits the malicious URL while authenticated to AVideo, the injected JavaScript executes in their browser context. The attacker's payload can access and exfiltrate the victim's username and password hash that are already present in the page's JavaScript context.

The vulnerability can be exploited by injecting JavaScript that escapes the existing string context and adds malicious code. This could involve using string terminators and script injection patterns to break out of the intended JavaScript variable assignment and execute attacker-controlled code. The attack requires no privileges on the target system but does require the victim to be authenticated to maximize impact through credential theft.

Detection Methods for CVE-2026-34375

Indicators of Compromise

• Unusual URL parameters containing JavaScript code patterns such as <script>, javascript:, or encoded variants in the plugin parameter
• Web server access logs showing requests to Stripe payment confirmation pages with suspicious query strings
• Browser console errors or unexpected script execution on payment-related pages
• Reports of credential theft or unauthorized account access following visits to payment pages

Detection Strategies

• Implement Web Application Firewall (WAF) rules to detect and block XSS payloads in URL parameters
• Monitor HTTP request logs for suspicious patterns in the plugin parameter targeting YPTWallet Stripe endpoints
• Deploy client-side XSS detection through Content Security Policy (CSP) violation reporting
• Use runtime application self-protection (RASP) solutions to detect JavaScript injection attempts

Monitoring Recommendations

• Enable detailed logging for all requests to the YPTWallet and Stripe-related endpoints
• Configure alerting for unusual patterns in query string parameters, particularly those containing script-related keywords
• Monitor for anomalous outbound connections from client browsers that may indicate credential exfiltration
• Review authentication logs for signs of credential compromise following suspected XSS attacks

How to Mitigate CVE-2026-34375

Immediate Actions Required

• Upgrade WWBN AVideo to a version containing the security fix (commit fa0bc102493a15d79fe03f86c07ab7ca1b5b63e2 or later)
• If immediate patching is not possible, consider temporarily disabling the YPTWallet Stripe payment functionality
• Implement a Content Security Policy (CSP) header to restrict inline script execution
• Review web server logs for any evidence of prior exploitation attempts

Patch Information

The vulnerability is fixed in commit fa0bc102493a15d79fe03f86c07ab7ca1b5b63e2. Administrators should update their AVideo installations to incorporate this fix. The commit addresses the input sanitization issue by properly encoding the plugin parameter before outputting it in the JavaScript context. For detailed information about the fix, refer to the GitHub Commit Details and the GitHub Security Advisory GHSA-pm37-62g7-p768.

Workarounds

• Deploy a WAF rule to sanitize or block requests containing suspicious characters in the plugin parameter
• Implement Content Security Policy headers with strict script-src directives to prevent inline script execution
• Consider restricting access to payment confirmation pages to authenticated sessions only with additional CSRF protection
• As a temporary measure, modify the application code to manually sanitize the plugin parameter using appropriate encoding functions

# Example Content Security Policy header configuration for Apache
# Add to .htaccess or virtual host configuration
Header set Content-Security-Policy "default-src 'self'; script-src 'self'; style-src 'self' 'unsafe-inline'; img-src 'self' data:; frame-ancestors 'none';"