Threat Intelligence Database

WWBN AVideo versions 12.4 through 29.2.0 contain a stored cross-site scripting (XSS) vulnerability. Authenticated uploaders can exploit this by submitting doubly-encoded entities in video titles, bypassing the safeString() sanitization function. This allows injection of malicious HTML that executes in various pages such as trending, gallery, embed, and playlist pages.

WWBN AVideo versions up to 29.2.0 contain a stored cross-site scripting (XSS) vulnerability. This flaw allows users with upload permissions to inject malicious scripts via the video trailer URL, which is rendered without proper escaping in certain templates and playlists. Exploitation can lead to arbitrary JavaScript execution in other users' browsers.

AVideo versions before 29.1.0 contain a stored cross-site scripting (XSS) vulnerability in the video trailer1 field. This field is rendered unsanitized within an inline onclick JavaScript string, allowing attackers with video upload permissions to inject HTML entity-encoded payloads. These payloads bypass URL validation and are decoded by browsers, enabling execution of arbitrary code in visitors' sessions, including administrators. The vulnerability has a medium severity with a CVSS score of 5.1.

WWBN AVideo through commit e01e41ecc (no patched version available) contains a broken access control flaw in objects/userVerifyEmail.php. The script disables the login requirement ($global['ignoreUserMustBeLoggedIn'] = 1), takes users_id directly from the query string, and calls User::sendVerificationLink() with no session requirement, no CSRF/global token, no relationship check between caller and target, and no enforceRateLimit() call. The only intended throttle is keyed to the caller's own session, so cookie-less requests are never limited. An unauthenticated remote attacker can therefore cause an arbitrary number of verification emails to be sent to any account ID, and can enumerate accounts and their verification status from the three distinct JSON responses ("Verification Sent", "Already verified", "Unknown error"). In addition, createVerificationCode() invokes $user->setRecoverPass() and saves the user, so each anonymous request writes a live password-recovery token onto the targeted account; that token is embedded in base64 in the verification link emailed to the account owner and is accepted by objects/userRecoverPassSave.json.php as the credential for setting a new password.

AVideo through commit c3edcc274c389816d434acadac07ee78eaf330c1 uses a cryptographically weak pseudo-random number generator when creating account activation / login pairing codes. getRandomCode() in objects/functions.php derives the code entirely from uniqid() (sprintf('%08x%05x', seconds, microseconds)) with a single non-CSPRNG rand() character used only as padding, reducing the code space to roughly 36 x 10^6 (~2^25) values for a known generation second. Because plugin/API/set.json.php?APIName=login_code can be called without authentication, it also serves as an oracle for the server's exact microtime. An unauthenticated remote attacker who guesses a valid, unexpired code (codes expire after 10 minutes) can redeem it at plugin/API/get.json.php?APIName=login_code to obtain the target account's email address and a User::getUserHash(users_id, '+1 year') value, a credential accepted in place of the account password for one year, resulting in account takeover. No patched version is available.

AVideo through c3edcc274c389816d434acadac07ee78eaf330c1 uses cryptographically weak uniqid() values for RTMP publish keys in LiveTransmition, reducing key entropy to approximately one million possibilities per creation second. Attackers who know the channel creation time can brute-force the five-digit microsecond component to forge valid stream keys and broadcast content as the channel owner.

AVideo versions up to and including 29.0 have a missing authorization check in the set_api_comment function. This flaw allows authenticated users to post comments on videos that are password-protected or restricted to certain groups, bypassing intended access controls. Attackers can exploit this by sending POST requests with arbitrary video IDs to the comment API endpoint, enabling them to comment on videos they are not authorized to watch.

AVideo through 29.0 (commit c3edcc274c389816d434acadac07ee78eaf330c1) fails to validate video access permissions in the API like endpoint, allowing logged-in users to vote on password-protected and group-restricted videos. Attackers can submit like and dislike requests to increment vote counters on videos they cannot watch by calling the set.json.php endpoint with APIName parameters.

AVideo through 29.0 (current revision e01e41ecc) contains a stored cross-site scripting vulnerability. The unauthenticated view-counter endpoint objects/videoAddViewCount.json.php reaches VideoStatistic::save(), which writes the caller's User-Agent (via getUserAgentInfo(), which returns unrecognized agent strings verbatim) directly into the `app` column of the videos_statistics table without invoking the sanitizing setter setApp(); normalizeApp() only truncates the value to 45 characters. The video owner's and administrator's statistics page (view/videoViewsInfo.php) renders this field in a DataTables 1.12.1 column with an unescaped renderer, and DataTables assigns cell content using innerHTML, so attacker-supplied HTML is parsed and executed in the privileged user's authenticated session when the statistics page is viewed. No patched version was available at the time of the advisory.

CVE-2026-92583 is a medium severity vulnerability in WWBN AVideo versions up to and including 29.0. It involves a race condition in the enforceRateLimit() function that allows attackers to bypass login brute-force protections by issuing concurrent authentication requests. This flaw enables attackers to exceed the intended limit of 30 login attempts per 5 minutes by an arbitrary factor based on connection concurrency.