AVideo Has a Critical Authentication Bypass — Steal the Hash, Become Admin

• The Mess: AVideo accepts a user’s stored users.password hash as a valid password through two separate authentication paths. If an attacker obtains the hash, there is no password cracking step — the hash itself can be replayed to log in.
• The Damage: An exposed administrator hash can become an administrator session, turning a database leak into direct application takeover.
• The Fix: Treat users.password as compromised, audit how hashes could have leaked, and apply the complete upstream fix as soon as a patched release becomes available.

The bug is worse than a normal password-hash leak

CVE-2026-92578 affects WWBN AVideo through version 29.0 and is classified as an improper authentication vulnerability, CWE-287.

The core problem is brutally simple: AVideo can compare the supplied password directly against the stored password hash and accept the request when the two strings match.

That completely changes the consequences of a database compromise.

Normally, stealing a password hash gives an attacker another problem to solve. They need to crack the hash or find the plaintext password.

Here, they don’t.

The stored value can become the login credential itself. The official AVideo security advisory demonstrates that submitting the administrator’s users.password value through the normal login mechanism establishes a valid administrator session.

The current CVE record rates the issue 8.1 High under CVSS 3.1 and 9.2 Critical under CVSS 4.0. The upstream GitHub security advisory independently assigns 9.8 Critical. The scoring difference comes from the published scoring models and metrics; the underlying authentication flaw is the same.

Two authentication paths accept the hash

This is not a single broken conditional buried in one forgotten endpoint.

The researcher found two independent paths.

The first lives in User::loginFromRequest().

AVideo attempts authentication normally, but if that attempt fails it retries with the opposite interpretation of the supplied credential. A value that was supposed to be treated as a normal password can therefore be processed as an already encoded password.

That second interpretation skips the normal hashing operation and allows the submitted string to be compared directly with the stored hash.

The second path is even more explicit.

Inside encryptPasswordVerify(), the legacy branch effectively performs:

password == stored_hash

and returns success.

The important detail is that this branch does not depend on the caller setting an encodedPass flag.

Both paths therefore converge on the same security failure: a database password hash can function as a password.

Removing only one of them is not enough. The advisory documents testing showing that disabling either path individually still left authentication bypass possible. Both changes are required to close the vulnerability.

The administrator account is not theoretical

The upstream advisory tested the issue against an administrator account.

A request containing the stored password hash produced a successful login, and the resulting session could subsequently access an endpoint that confirmed administrator privileges.

That matters because it proves the vulnerability is not merely an authentication edge case returning a misleading HTTP response.

The application creates a real authenticated session.

The advisory also notes that the login endpoint returns HTTP 200 regardless of authentication success, so the application-level response — including the returned user ID — must be inspected when testing for the flaw.

How does an attacker obtain the hash?

CVE-2026-92578 does not magically reveal the database.

The attacker still needs access to a users.password value.

That can come from another vulnerability, a compromised database, an exposed backup, a replica, an SQL injection, an application endpoint leaking user records, or logs containing database data.

And this is where the AVideo vulnerability becomes particularly nasty.

The upstream research explicitly points out that other information-disclosure flaws can expose users.password. Once the value is obtained, the attacker does not need to crack it. They can replay it against authentication endpoints.

This creates a dangerous vulnerability chain:

data disclosure → password hash theft → credential replay → authenticated session → account takeover

For an administrator account, the final step can mean control over the AVideo installation and the content it manages.

GET authentication makes things uglier

The affected authentication logic is not limited to a conventional POST login flow.

The advisory demonstrates authentication through a GET request carrying the username and password parameters.

That matters operationally because credentials placed in URLs can leak into reverse-proxy logs, web-server logs, browser history, monitoring systems, analytics pipelines and other infrastructure.

In this case, the vulnerable authentication code is also reachable from broader request handling. The researcher identified numerous endpoints capable of receiving user and pass parameters rather than relying exclusively on one login page.

That expands the number of places defenders should investigate after a suspected compromise.

The patch requires two changes

The upstream suggested fix removes both vulnerable behaviors.

First, AVideo needs to stop retrying a failed password as though it were already encoded.

Second, the legacy equality check accepting:

submitted_password == stored_hash

must disappear.

The advisory states that the legitimate pre-encoded-password API behavior can remain available when explicitly requested. What must disappear is the implicit acceptance of the stored hash as a normal password.

There is an important deployment problem, however.

The current upstream security advisory lists the affected code as current and earlier and does not list a patched version. The CVE record likewise identifies AVideo through 29.0 as affected.

So administrators should not assume that simply upgrading to an arbitrary newer build resolves the issue unless the release explicitly contains the two upstream authentication changes.

What defenders should check now

If AVideo is exposed to the Internet, treat this as an incident-response problem when there is evidence that password hashes may have been exposed.

Check:

• database access logs
• SQL injection attempts
• application endpoints returning user records
• database backups and replicas
• web-server access logs
• requests containing user and pass
• suspicious administrator logins
• unexpected sessions
• newly created administrator accounts
• changes to videos, users, plugins and configuration
• outbound connections from the AVideo host
• PHP files or other unexpected files created after suspicious authentication activity

If an administrator password hash has been exposed, changing only the plaintext password is not enough unless the authentication vulnerability itself is closed.

The old hash may remain usable while the vulnerable comparison exists.

No need to crack the hash

This is the part defenders should remember.

Password hashing normally creates a one-way barrier between stolen database material and usable credentials.

AVideo accidentally turns that barrier into a shortcut.

The cryptographic strength of the stored hash becomes largely irrelevant when the application accepts the hash itself as proof of identity.

That is why a seemingly ordinary database disclosure can escalate into immediate account compromise.

Exploitation status

CVE-2026-92578 was published on September 16, 2026.

The current records do not establish confirmed active exploitation or a CISA KEV listing for this vulnerability. There is also no public exploit listed in the sources reviewed for this article.

That does not make exposed AVideo installations safe.

The vulnerability is straightforward to understand, the upstream advisory contains a working proof of concept, and exploitation becomes significantly more serious when combined with any mechanism capable of disclosing users.password.

Bugstoday’s take

This is exactly the kind of authentication bug that turns a seemingly contained database leak into a much larger compromise.

The dangerous part is not that AVideo stores password hashes.

The dangerous part is that the application can treat one of those hashes as the password.

That destroys the security boundary the hash was supposed to provide.

If you run AVideo, don’t wait for somebody to publish a mass scanner. Check how users.password could be exposed, inspect authentication logs, and verify that both vulnerable authentication paths have been removed before treating the system as clean.

Today’s Bugs. Tomorrow’s Breaches.

Technical Sources

• WWBN AVideo — official security advisory GHSA-fq38-jp6c-q4cx
• CVE-2026-92578 — CVE record
• NVD — CVE-2026-92578