CVE-2026-33499

The view/forbiddenPage.php and view/warningPage.php templates reflect the $_REQUEST['unlockPassword'] parameter directly into an HTML <input> tag's attributes without any output encoding or sanitization. An attacker can craft a URL that breaks out of the value attribute and injects arbitrary HTML attributes including JavaScript event handlers, achieving reflected XSS against any visitor who clicks the link.

Details

When a user visits a password-protected channel, view/channel.php:22 calls:

forbiddenPage('This channel is password protected', false, $channelPassword);

The forbiddenPage() function in objects/functionsSecurity.php:520 checks whether the supplied password matches. If it doesn't (or no password was submitted), it includes view/forbiddenPage.php at line 561.

In view/forbiddenPage.php:31-35, the raw request parameter is reflected into HTML:

$value = '';
if (!empty($_REQUEST['unlockPassword'])) {
    $value = $_REQUEST['unlockPassword'];  // Line 33: unsanitized user input
}
echo getInputPassword('unlockPassword', 'class="form-control" value="' . $value . '"', __('Unlock Password'));

The getInputPassword() function at objects/functions.php:4490 outputs the $attributes string directly into the <input> tag at line 4502:

<input id="<?php echo $id; ?>" name="<?php echo $id; ?>" type="password" placeholder="<?php echo $placeholder; ?>" <?php echo $attributes; ?>>

The unlockPassword parameter is not listed in any of the security filter arrays defined in objects/security.php:4-8 ($securityFilter, $securityFilterInt, $securityRemoveSingleQuotes, $securityRemoveNonChars, $securityRemoveNonCharsStrict, $filterURL), so it passes through the global input sanitization completely unfiltered.

Commit 3933d4abc added sanitization only for the server-side password comparison in functionsSecurity.php:529 (preg_replace('/[^0-9a-z]/i', '', ...)), but did not address the client-side reflection in the view templates.

The identical vulnerability exists in view/warningPage.php:31-34.

PoC

Step 1: Identify a password-protected channel (or any page that triggers forbiddenPage() with an $unlockPassword).

Step 2: Craft a URL with a malicious unlockPassword parameter that breaks out of the value attribute:

https://target.com/channel/someuser?unlockPassword=" autofocus onfocus="alert(document.cookie)

Step 3: The server renders the following HTML:

<input id="unlockPassword" name="unlockPassword" type="password"
  placeholder="Unlock Password"
  class="form-control" value="" autofocus onfocus="alert(document.cookie)">

The autofocus attribute causes the browser to immediately focus the input element on page load, triggering the onfocus event handler which executes the attacker-controlled JavaScript. No further user interaction is required beyond clicking the link.

Step 4: The JavaScript executes in the context of the target domain, with access to cookies (no CSP or HttpOnly protections were observed), DOM, and the ability to make authenticated requests on behalf of the victim.

• Session hijacking: An attacker can steal PHPSESSID cookies and impersonate any user (including administrators) who clicks the crafted link.
• Account takeover: The injected JavaScript can change the victim's email/password by submitting forms to the application's account settings endpoints.
• Phishing: The attacker can overlay fake login forms or redirect users to credential harvesting pages.
• No authentication required: The vulnerable page is specifically shown to unauthenticated/unauthorized users, making the attack surface broad.

Untrusted input is rendered as active markup in a victim's browser, which can run script in their session. Typical impact: session or credential theft, and actions taken as the user.

CVE-2026-33499 has a CVSS score of 6.1 (Medium). The vector is network-reachable, no privileges required, and user interaction required. A CVSS score reflects the worst-case severity of the vulnerability, not your specific exposure. Whether this affects your application depends on whether the vulnerable code is present and reachable in your environment. No fixed version is listed yet, so configuration controls and monitoring matter more in the interim.

Kodem intelligence

Apply htmlspecialchars() output encoding to the reflected value in both view/forbiddenPage.php and view/warningPage.php:

view/forbiddenPage.php, change line 33:

// Before (vulnerable):
$value = $_REQUEST['unlockPassword'];

// After (fixed):
$value = htmlspecialchars($_REQUEST['unlockPassword'], ENT_QUOTES, 'UTF-8');

view/warningPage.php, change line 32:

// Before (vulnerable):
$value = $_REQUEST['unlockPassword'];

// After (fixed):
$value = htmlspecialchars($_REQUEST['unlockPassword'], ENT_QUOTES, 'UTF-8');

Alternatively, add 'unlockPassword' to the $securityFilter array in objects/security.php:4 to apply the global XSS filter, though explicit output encoding at the point of use is the more robust defense-in-depth approach.

1. What is CVE-2026-33499? CVE-2026-33499 is a medium-severity cross-site scripting (XSS) vulnerability in wwbn/avideo (composer), affecting versions <= 26.0. No fixed version is listed yet. Untrusted input is rendered as active markup in a victim's browser, which can run script in their session.
2. How severe is CVE-2026-33499? CVE-2026-33499 has a CVSS score of 6.1 (Medium). This score reflects the worst-case severity of the vulnerability, not your specific exposure. Whether it represents real risk in your environment depends on whether the vulnerable code is present and reachable.
3. Which versions of wwbn/avideo are affected by CVE-2026-33499? wwbn/avideo (composer) versions <= 26.0 is affected.
4. Is there a fix for CVE-2026-33499? No fixed version is listed for CVE-2026-33499 yet. Monitor the advisory for updates and apply mitigations in the interim.
5. Is CVE-2026-33499 exploitable, and should I be worried? Whether CVE-2026-33499 is exploitable in your environment depends on whether the vulnerable code is present and reachable. A CVSS score is a worst-case rating; it does not account for your specific deployment, configuration, or usage patterns. Kodem, an Intelligent Application Security platform, uses runtime intelligence to show which vulnerabilities actually execute in production, so you can focus on the ones that represent real risk. Get a demo
6. What actually determines whether CVE-2026-33499 is exploitable, and how bad it is? Exploitability and impact are not fixed properties of a CVE. They depend on runtime truth: whether the vulnerable code is present, reachable, and actually executes in your application. A high CVSS score on a dependency that never runs is not the same as real risk. Kodem, an Intelligent Application Security platform, uses runtime intelligence to reveal which vulnerabilities actually execute in production, so teams prioritize the ones that genuinely matter.
7. How do I fix CVE-2026-33499? No fixed version is listed yet. In the interim: Validate and encode untrusted input before rendering it as HTML. Applying a Content Security Policy reduces the impact if encoding is bypassed.