CVE-2026-86729 in AVideo
Summary
by MITRE • 09/08/2026
WWBN AVideo through commit e01e41ecc (no patched version available) exposes get_api_preauthorize in plugin/API/API.php as a second, undocumented login path. Unlike get_api_signIn, which enforces a rate limit of 10 attempts per 5 minutes via checkRateLimit(), get_api_preauthorize performs the same credential check with no throttling for any client, allowing unlimited remote password guessing against arbitrary accounts, including admin. The endpoint also acts as a credential oracle: it returns the message "Invalid credentials" for both correct and incorrect passwords, while the users_id field in the response body discloses the authenticated identity (users_id:1 on success, users_id:0 on failure), and a correct password establishes a session cookie that remains usable for authenticated API requests. Together these issues permit unauthenticated brute-force account takeover.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 09/08/2026
The vulnerability identified in WWBN AVideo through commit e01e41ecc represents a critical authentication bypass mechanism rooted in the improper implementation of rate limiting and credential validation logic within the application's API layer. Specifically, the function get_api_preauthorize located in plugin/API/API.php serves as an undocumented secondary login path that operates independently from the standard get_api_signIn endpoint. While the primary sign-in method correctly implements a security control by enforcing a strict rate limit of ten attempts per five minutes via the checkRateLimit() function to mitigate automated attacks, this protective measure is entirely absent in the preauthorize endpoint. This architectural inconsistency creates an asymmetric defense posture where one entry point is hardened against brute-force enumeration while another remains completely exposed, allowing attackers to bypass intended security controls by simply targeting the undocumented API method rather than the public-facing login page.
From a technical perspective, the flaw constitutes a classic case of missing rate limiting combined with information disclosure through response analysis. The get_api_preauthorize endpoint performs credential verification without any throttling mechanism for any client IP or session identifier. This lack of restriction allows an unauthenticated attacker to send unlimited authentication requests against arbitrary user accounts, including high-privilege administrative accounts, at a speed limited only by network latency and server processing capacity. Furthermore, the API exhibits behavior characteristic of a timing oracle or response-based credential validator. Although the error message returned is uniformly "Invalid credentials" for both successful and failed login attempts, the users_id field in the JSON response body provides definitive feedback regarding authentication status. A return value of users_id:1 indicates that the provided username and password combination was valid and authenticated, whereas a value of users_id:0 signifies failure. This binary signal effectively transforms the endpoint into a credential oracle, enabling precise verification of guessed passwords without triggering account lockouts or detection mechanisms typically associated with brute-force attacks.
The operational impact of this vulnerability is severe, as it facilitates unauthenticated remote code execution potential through full account takeover. By leveraging the unlimited guessing capability and the clear success/failure indicators in the response body, an attacker can systematically enumerate valid usernames and crack passwords using automated tools such as Hydra or custom scripts. The establishment of a session cookie upon successful authentication further exacerbates the risk, as this token remains usable for subsequent authenticated API requests. This means that once credentials are compromised via brute force, the attacker gains persistent access to the application's features under the context of the stolen account. If an administrative account is targeted and successfully guessed, the implications extend beyond simple data theft to include complete system compromise, potential modification of site configurations, insertion of malicious content, or exploitation of other vulnerabilities that require elevated privileges.
This vulnerability aligns with several well-known industry standards for software security flaws. It maps directly to CWE-307 Improper Restriction of Excessive Authentication Attempts, which describes scenarios where an application fails to limit the number of login attempts within a given timeframe. Additionally, it relates to CWE-209 Generation of Error Message Containing Sensitive Information, as the response body leaks authentication status through the users_id field despite masking the textual error message. In terms of offensive security frameworks, this exploit scenario is categorized under MITRE ATT&CK technique T1110 Brute Force, specifically illustrating how attackers can bypass rate limiting controls by identifying alternative endpoints or undocumented APIs that lack equivalent protections. The use of session cookies for maintaining authenticated state also touches upon CWE-613 Insufficient Session Expiration if the tokens are not properly invalidated after compromise detection.
Mitigation strategies must address both the immediate technical flaw and broader architectural security practices. Since no patched version is currently available, administrators should implement network-level controls such as Web Application Firewall rules to block or rate-limit requests to the /plugin/API/API.php endpoint with a method of get_api_preauthorize. It is critical to disable or remove this undocumented login path entirely if it serves no essential business function, thereby eliminating the attack vector at its source. For environments where immediate patching is not feasible, implementing IP-based throttling via reverse proxy configurations like Nginx or Apache can simulate the missing application-level rate limiting. Additionally, enabling multi-factor authentication for all user accounts, particularly administrators, would significantly raise the barrier to entry even if passwords are successfully guessed through brute force. Long-term remediation requires a comprehensive code audit to identify other undocumented endpoints that may lack similar security controls and ensuring consistent implementation of anti-automation measures across all API methods.