WWBN AVideo CVE-2026-92578

The decisive prerequisite is prior possession of the victim's stored users.password hash value from the AVideo database - the bypass lets that raw hash be submitted directly to the login endpoints as if it were the password (via loginFromRequest() and encryptPasswordVerify()). This maps to the vendor's AT:P (Attack Requirements: Present): although the login endpoint itself needs no prior authentication (PR:N), the attacker cannot exploit this without first exfiltrating the hash through a separate vector (SQL injection, leaked/stolen database backup, insider access, or another breach). It affects WWBN AVideo through version 29.0 in default configuration once the hash is known; no user interaction is required. The limiting factor is therefore the difficulty of obtaining the stored hash - absent that, the flaw is not directly exploitable, which is why it functions as a privilege/compromise amplifier rather than an initial-access vulnerability.

This is a high-CVSS-4.0 (9.2) authentication bypass, but the real-world risk is materially lower than the headline score because exploitation is fundamentally a post-compromise, pass-the-hash primitive. The vendor CVSS 4.0 vector carries PR:N (no authentication to the login endpoint) yet also AT:P (Attack Requirements: Present), which is the key signal - the attacker must first obtain the stored users.password hash value before the bypass is usable. That prerequisite typically implies prior database access (SQL injection, backup leak, insider, or another breach), so the flaw amplifies an existing compromise into full account takeover rather than granting initial access on its own. No CISA KEV listing, no public exploit code, and no EPSS score are present in the provided data, so exploitation status is 'no public exploit identified at time of analysis' - do not treat this as actively exploited. The signals are internally consistent (network vector, low complexity once the hash is held, high C/I/A because any account including admin can be assumed), but the AT:P/hash-prerequisite is the decisive limiter and should drive prioritization: patch promptly, but treat this as a defense-in-depth failure that matters most where a hash disclosure is plausible.

An attacker who has already obtained the AVideo database (e.g., via a separate SQLi, leaked backup, or insider access) reads a target user's stored password hash from the users table and submits that raw hash directly to the login endpoint. Because loginFromRequest() and encryptPasswordVerify() both accept the stored hash as a valid credential, the attacker is authenticated as that user - including administrators - without ever knowing the plaintext password. No public proof-of-concept is identified in the provided sources.