CVE-2026-92915 in AVideo
Summary
by MITRE • 09/17/2026
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.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 09/17/2026
The vulnerability identified in WWBN AVideo represents a critical failure in access control mechanisms, specifically within the user email verification module. This flaw stems from a design decision where the script disables standard authentication requirements by setting an ignore flag, thereby allowing unauthenticated users to interact with sensitive functionality. The core technical issue lies in the direct acceptance of a target user identifier from the query string without any validation or authorization checks. When this endpoint is invoked, it bypasses session verification and Cross-Site Request Forgery protections entirely. Furthermore, there are no rate-limiting controls applied to requests that do not originate with an active browser session, creating a significant avenue for abuse by remote attackers who can operate anonymously using cookie-less HTTP clients.
From an operational perspective, this vulnerability allows an unauthenticated attacker to perform two distinct malicious actions: account enumeration and unauthorized password reset initiation. By sending repeated requests with different user identifiers, the attacker can determine which accounts exist in the system based on specific JSON responses indicating whether a verification email was sent or if the account is already verified. This information leakage facilitates targeted attacks against known users. More critically, each request triggers the generation of a live password recovery token associated with the target account. This token is embedded within a base64-encoded link contained in an email sent to the victim. Because this token serves as the primary credential for resetting passwords via another endpoint, its exposure effectively grants the attacker full control over the targeted user's account if they can intercept or predict the resulting password reset action.
This flaw aligns with CWE-285 Improper Authorization and CWE-798 Use of Hard-coded Credentials in a broader sense regarding the trust placed in external inputs without validation. In terms of attack vectors, it corresponds to MITRE ATT&CK techniques involving Account Manipulation and Credential Access, specifically through the exploitation of authentication bypasses and token theft. The lack of rate limiting for anonymous requests exacerbates the severity by enabling high-volume enumeration and mass-token generation attacks that could overwhelm email services or facilitate large-scale account takeovers.
Mitigation strategies must focus on restoring strict access controls to this endpoint. First, all operations involving user verification or password recovery should require a valid session token tied to an authenticated administrator or system process, rather than relying solely on client-side inputs. Second, robust rate limiting mechanisms must be implemented that track requests based on source IP address and other non-session identifiers to prevent abuse by unauthenticated actors. Additionally, the application of CSRF tokens is essential for any state-changing operation exposed via HTTP GET parameters. Finally, immediate patching or code modification to remove the ability to trigger these functions without proper authorization checks is required to eliminate the risk of account enumeration and unauthorized password resets.