WWBN AVideo is an open source video platform. Prior to version 26.0, WWBN/AVideo contains an open redirect vulnerability in the login flow where a user-supplied redirectUri parameter is reflected directly into a JavaScript `document.location` assignment without JavaScript-safe encoding. After a user completes the login popup flow, a timer callback executes the redirect using the unvalidated value, sending the victim to an attacker-controlled site. Version 26.0 fixes the issue.

Affected: Packagist: wwbn/avideo

### Summary

WWBN/AVideo contains an open redirect vulnerability in the login flow where a user-supplied redirectUri parameter is reflected directly into a JavaScript `document.location` assignment without JavaScript-safe encoding. After a user completes the login popup flow, a timer callback executes the redirect using the unvalidated value, sending the victim to an attacker-controlled site.

### Details

In `view/userLogin.php`, the application accepts a redirectUri GET parameter, passes it through a function called `isSafeRedirectURL()`, and stores the result in $safeRedirectUri. This value is then embedded into an inline JavaScript block:

```php var logintimer = setInterval(function() { if (win.closed) { clearInterval(logintimer); document.location = "<?php print $safeRedirectUri; ?>"; } }, 1000); ```

The value is printed directly into a JavaScript string literal with no call to `json_encode()`, `htmlspecialchars()`, or any JavaScript-context escaping. Even if `isSafeRedirectURL()` is intended to filter dangerous values, protocol-relative URLs such as `//evil.com` satisfy many naive URL validation checks because they carry no explicit scheme, yet browsers will resolve them as `https://evil.com` when embedded in a navigation target. Additional bypass vectors include subdomain confusion of the form `https://trusted.com.evil.com` and path-prefix matching weaknesses. Because the reflected value lands inside a JavaScript string rather than an HTML at…