CVE-2026-82644 in AVideo
Summary
by MITRE • 08/30/2026
WWBN AVideo (current e01e41ecc and earlier) contains a brute-force rate limiting bypass in enforceRateLimit(), which protects login.json.php and 13 other endpoints. The function stores its attempt counter via a cache layer (ObjectYPT::setCacheGlobal) that silently discards writes for any client identified as a bot by isBot(). Because isBot() treats a missing User-Agent header as a bot by default — and also matches common bot identifiers such as 'curl', 'bot', 'crawler', and 'spider' — the counter never increments for such clients, so the rate limit never fires. An unauthenticated attacker can therefore submit unlimited login attempts (e.g., by omitting the User-Agent header or using curl's default User-Agent), enabling unrestricted password-guessing attacks.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 08/30/2026
The vulnerability in WWBN AVideo versions up to e01e41ecc represents a critical authentication bypass rooted in flawed logic within the rate limiting enforcement mechanism. The application utilizes an enforceRateLimit function designed to protect login.json.php and thirteen other sensitive endpoints from automated attacks by tracking failed attempts through a caching layer implemented via ObjectYPT::setCacheGlobal. This security control is intended to throttle brute-force efforts, yet it contains a significant logical flaw that allows attackers to circumvent these protections entirely. The core issue lies in the interaction between the rate limiting logic and the bot detection routine known as isBot(). When an authentication attempt occurs, the system checks if the client is identified as a bot before incrementing the failure counter stored in the cache. If the client is deemed a bot, the write operation to the cache is silently discarded, meaning no record of the failed login attempt is kept for that specific source IP or session identifier.
The mechanism by which clients are classified as bots introduces this vulnerability through overly broad and default-heavy criteria. The isBot() function treats any request lacking a User-Agent header as a bot by definition. Furthermore it matches common user agent strings associated with automated tools such as curl, bot, crawler, and spider. This design choice creates a trivial bypass vector for attackers who are familiar with standard HTTP client behaviors or scripting languages like Python, Go, or C++. By simply omitting the User-Agent header from their requests or explicitly setting it to one of the recognized bot identifiers, an attacker can ensure that every failed login attempt is ignored by the rate limiting system. Consequently, the counter never increments for these specific clients, and the threshold required to trigger a lockout or delay mechanism is never reached.
From an operational perspective this flaw enables unrestricted password guessing attacks against user accounts without any resistance from the application's native defenses. An unauthenticated attacker can script automated tools to submit thousands of login attempts per minute targeting valid usernames with common passwords or dictionary words. The lack of rate limiting means that there are no delays between requests and no temporary bans after a certain number of failures, significantly reducing the time required to compromise accounts through brute force methods. This is particularly dangerous for applications where user credentials may be reused across other services or where account takeover could lead to data exfiltration privilege escalation if administrative roles are involved. The impact extends beyond simple credential theft as it also facilitates denial of service conditions by exhausting backend resources during high-volume authentication attempts since the rate limiter fails to throttle traffic from these bypassing clients.
This vulnerability aligns with CWE-307 Improper Restriction of Excessive Authentication Attempts, which describes flaws where an application does not adequately limit the number of login or other security-related transactions within a given timeframe. Additionally it maps to MITRE ATT&CK technique T1110 Brute Force specifically subtechnique T1110.001 Password Guessing and potentially T1110.003 Credential Stuffing depending on whether the attacker uses leaked credential lists or simple dictionaries. The root cause is a logic error in security control implementation where defensive measures are bypassed due to incorrect assumptions about client identity rather than a failure of encryption or input validation per se.
Mitigation strategies must address both the immediate code flaw and broader authentication hardening practices. Developers should modify the enforceRateLimit function to ensure that rate limiting counters are incremented regardless of whether the client is identified as a bot, or alternatively refine the isBot() logic to be more specific about what constitutes malicious automation rather than relying on broad heuristics like missing headers which legitimate users might occasionally trigger due to privacy extensions or network proxies. Implementing account lockout policies that persist across sessions and are not solely dependent in-memory caches can also help mitigate this risk since cache-based counters may be lost during restarts but database-backed locks would remain effective. Furthermore organizations should deploy Web Application Firewalls configured with rules specifically targeting missing User-Agent headers for login endpoints or enforcing strict user-agent validation as an additional layer of defense. Rate limiting should ideally be implemented at the network edge using reverse proxies such as Nginx or Apache modules which are less susceptible to application-level logic errors and can enforce limits based on IP address regardless of HTTP header content ensuring that brute force attacks are throttled effectively even if the underlying application fails to do so correctly.