CVE-2026-86729: WWBN AVideo Unrestricted Authentication Attempts via get_api_preauthorize
WWBN AVideo through commit e01e41ecc (no patched version available) exposes getapipreauthorize in plugin/API/API.php as a second, undocumented login path. Unlike getapisignIn, which enforces a rate limit of 10 attempts per 5 minutes via checkRateLimit(), getapipreauthorize 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 usersid field in the response body discloses the authenticated identity (usersid:1 on success, usersid: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.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade to a fixed release to a version that resolves this vulnerability.
Patch e01e41ecc - Configuration
Disable/remove the undocumented second login path get_api_preauthorize in plugin/API/API.php so only the intended authentication mechanism (e.g., get_api_signIn) remains reachable.
WWBN AVideo (plugin/API/API.php) Exposure of get_api_preauthorize = disabled - Compensating control
Implement throttling/rate limiting for the get_api_preauthorize endpoint (unlike get_api_signIn, which uses checkRateLimit() for 10 attempts per 5 minutes).
Event History
Frequently Asked Questions
Which deployments and accounts are exposed?
Any WWBN AVideo deployment through commit e01e41ecc that exposes the API endpoint is affected. The unauthenticated endpoint can be used to guess passwords for arbitrary accounts, including administrator accounts.
What does an attacker need to exploit this?
An attacker needs only network access to the affected API endpoint and does not need an existing account or user interaction. Exploitation requires guessing a valid account password, but the endpoint imposes no authentication-attempt throttling.
How can an attacker tell whether a password guess succeeded?
The response message remains "Invalid credentials" for both successful and failed attempts, but the users_id response field distinguishes them: users_id:1 indicates an authenticated identity and users_id:0 indicates failure. A successful request also establishes a session cookie usable for authenticated API requests.
Is there a patch or documented temporary mitigation?
No patched version is available in the provided information. The affected endpoint is get_api_preauthorize in plugin/API/API.php; no specific workaround or configuration-based mitigation is documented.