GHSA-7292-W8QP-MHQ2
Vulnerability from github – Published: 2026-03-20 20:56 – Updated: 2026-03-25 20:31Summary
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.
Impact
- Session hijacking: An attacker can steal
PHPSESSIDcookies 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.
Recommended Fix
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.
{
"affected": [
{
"package": {
"ecosystem": "Packagist",
"name": "wwbn/avideo"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"last_affected": "26.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-33499"
],
"database_specific": {
"cwe_ids": [
"CWE-79"
],
"github_reviewed": true,
"github_reviewed_at": "2026-03-20T20:56:38Z",
"nvd_published_at": "2026-03-23T17:16:51Z",
"severity": "MODERATE"
},
"details": "## Summary\n\nThe `view/forbiddenPage.php` and `view/warningPage.php` templates reflect the `$_REQUEST[\u0027unlockPassword\u0027]` parameter directly into an HTML `\u003cinput\u003e` tag\u0027s 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.\n\n## Details\n\nWhen a user visits a password-protected channel, `view/channel.php:22` calls:\n```php\nforbiddenPage(\u0027This channel is password protected\u0027, false, $channelPassword);\n```\n\nThe `forbiddenPage()` function in `objects/functionsSecurity.php:520` checks whether the supplied password matches. If it doesn\u0027t (or no password was submitted), it includes `view/forbiddenPage.php` at line 561.\n\nIn `view/forbiddenPage.php:31-35`, the raw request parameter is reflected into HTML:\n```php\n$value = \u0027\u0027;\nif (!empty($_REQUEST[\u0027unlockPassword\u0027])) {\n $value = $_REQUEST[\u0027unlockPassword\u0027]; // Line 33: unsanitized user input\n}\necho getInputPassword(\u0027unlockPassword\u0027, \u0027class=\"form-control\" value=\"\u0027 . $value . \u0027\"\u0027, __(\u0027Unlock Password\u0027));\n```\n\nThe `getInputPassword()` function at `objects/functions.php:4490` outputs the `$attributes` string directly into the `\u003cinput\u003e` tag at line 4502:\n```php\n\u003cinput id=\"\u003c?php echo $id; ?\u003e\" name=\"\u003c?php echo $id; ?\u003e\" type=\"password\" placeholder=\"\u003c?php echo $placeholder; ?\u003e\" \u003c?php echo $attributes; ?\u003e\u003e\n```\n\nThe `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.\n\nCommit `3933d4abc` added sanitization only for the server-side password **comparison** in `functionsSecurity.php:529` (`preg_replace(\u0027/[^0-9a-z]/i\u0027, \u0027\u0027, ...)`), but did not address the client-side reflection in the view templates.\n\nThe identical vulnerability exists in `view/warningPage.php:31-34`.\n\n## PoC\n\n**Step 1:** Identify a password-protected channel (or any page that triggers `forbiddenPage()` with an `$unlockPassword`).\n\n**Step 2:** Craft a URL with a malicious `unlockPassword` parameter that breaks out of the `value` attribute:\n\n```\nhttps://target.com/channel/someuser?unlockPassword=\" autofocus onfocus=\"alert(document.cookie)\n```\n\n**Step 3:** The server renders the following HTML:\n\n```html\n\u003cinput id=\"unlockPassword\" name=\"unlockPassword\" type=\"password\"\n placeholder=\"Unlock Password\"\n class=\"form-control\" value=\"\" autofocus onfocus=\"alert(document.cookie)\"\u003e\n```\n\nThe `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.\n\n**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.\n\n## Impact\n\n- **Session hijacking**: An attacker can steal `PHPSESSID` cookies and impersonate any user (including administrators) who clicks the crafted link.\n- **Account takeover**: The injected JavaScript can change the victim\u0027s email/password by submitting forms to the application\u0027s account settings endpoints.\n- **Phishing**: The attacker can overlay fake login forms or redirect users to credential harvesting pages.\n- **No authentication required**: The vulnerable page is specifically shown to unauthenticated/unauthorized users, making the attack surface broad.\n\n## Recommended Fix\n\nApply `htmlspecialchars()` output encoding to the reflected value in both `view/forbiddenPage.php` and `view/warningPage.php`:\n\n**view/forbiddenPage.php** \u2014 change line 33:\n```php\n// Before (vulnerable):\n$value = $_REQUEST[\u0027unlockPassword\u0027];\n\n// After (fixed):\n$value = htmlspecialchars($_REQUEST[\u0027unlockPassword\u0027], ENT_QUOTES, \u0027UTF-8\u0027);\n```\n\n**view/warningPage.php** \u2014 change line 32:\n```php\n// Before (vulnerable):\n$value = $_REQUEST[\u0027unlockPassword\u0027];\n\n// After (fixed):\n$value = htmlspecialchars($_REQUEST[\u0027unlockPassword\u0027], ENT_QUOTES, \u0027UTF-8\u0027);\n```\n\nAlternatively, add `\u0027unlockPassword\u0027` 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.",
"id": "GHSA-7292-w8qp-mhq2",
"modified": "2026-03-25T20:31:25Z",
"published": "2026-03-20T20:56:38Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/WWBN/AVideo/security/advisories/GHSA-7292-w8qp-mhq2"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-33499"
},
{
"type": "WEB",
"url": "https://github.com/WWBN/AVideo/commit/f154167251c9cf183ce09cd018d07e9352310457"
},
{
"type": "PACKAGE",
"url": "https://github.com/WWBN/AVideo"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:L/I:L/A:N",
"type": "CVSS_V3"
}
],
"summary": "AVideo has Reflected XSS via unlockPassword Parameter in forbiddenPage.php and warningPage.php"
}
Sightings
| Author | Source | Type | Date |
|---|
Nomenclature
- Seen: The vulnerability was mentioned, discussed, or observed by the user.
- Confirmed: The vulnerability has been validated from an analyst's perspective.
- Published Proof of Concept: A public proof of concept is available for this vulnerability.
- Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
- Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
- Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
- Not confirmed: The user expressed doubt about the validity of the vulnerability.
- Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.