CVE-2026-84479 in AVideo
Summary
by MITRE • 09/02/2026
WWBN AVideo (current e01e41ecc and earlier) makes three login-time security controls depend solely on the client-supplied User-Agent header. The isAVideoEncoder()/isAVideoMobileApp() checks match HTTP_USER_AGENT against a hardcoded literal ("AVideoEncoder"/"AVideoMobileApp") with no IP check or shared secret. An attacker who submits valid credentials and sets User-Agent: AVideoEncoder bypasses two-factor authentication, skips brute-force captcha escalation, and avoids being recorded in the login/device audit history. No patch is available at the time of publication.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 09/02/2026
The vulnerability identified in WWBN AVideo versions up to e01e41ecc represents a critical failure in access control mechanisms, specifically stemming from an over-reliance on client-supplied data for security decisions. The application implements three distinct login-time security controls that are gated exclusively by the value of the HTTP User-Agent header. These checks involve functions such as isAVideoEncoder and isAVideoMobileApp, which perform string matching against hardcoded literals like "AVideoEncoder" or "AVideoMobileApp." This architectural decision violates fundamental principles of secure system design, particularly the concept that security controls must never trust unvalidated input from clients for authentication or authorization purposes. By binding critical security logic to a header field that is trivially manipulable by any network actor, the application creates a severe bypass vector for attackers seeking to compromise user accounts without detection or restriction.
The operational impact of this flaw is significant and multifaceted. An attacker possessing valid credentials can manipulate their HTTP request headers to include User-Agent: AVideoEncoder. Upon submission, the server interprets this header as originating from an authorized internal tool rather than a standard web browser or mobile application. Consequently, two-factor authentication mechanisms are bypassed entirely, allowing direct access with only knowledge of the username and password. Furthermore, brute-force protection measures, such as CAPTCHA escalation after multiple failed attempts, are skipped because the system assumes the traffic is legitimate automated activity from an encoder tool. This effectively neutralizes defenses designed to prevent credential stuffing or dictionary attacks against user accounts.
Beyond immediate unauthorized access, this vulnerability facilitates stealthy reconnaissance and persistent compromise by evading audit trails. The application fails to record login events associated with requests bearing the manipulated User-Agent header in its device audit history. This lack of logging means that successful exploitation leaves no forensic evidence within the standard security logs, making it difficult for administrators to detect intrusions or track attacker movements across the system. The combination of bypassing multi-factor authentication and evading audit logging creates a high-severity risk where an adversary can maintain persistent access while remaining undetected by traditional monitoring tools.
From a classification perspective, this vulnerability aligns with CWE-287 Improper Authentication, as the application fails to adequately verify identity before granting access privileges. It also relates closely to CWE-345 Insufficient Verification of Data Authenticity, since the system trusts client-supplied headers without validation or integrity checks. In terms of offensive security frameworks, this behavior maps to MITRE ATT&CK technique T1078 Valid Accounts and potentially T1621 Multi-Factor Authentication Request Bypass. The exploitation method involves manipulating HTTP request parameters, which falls under common attack patterns involving header injection or spoofing techniques used in web application attacks.
Mitigation strategies for this vulnerability must address the fundamental architectural flaw of trusting client-side headers for security decisions. Since no patch is available at the time of publication, immediate defensive measures are required to protect affected instances. Administrators should implement reverse proxy rules or Web Application Firewall (WAF) configurations that validate and restrict User-Agent header values based on expected patterns rather than allowing arbitrary strings to trigger privileged code paths. It is critical to enforce strict allow-listing for internal tool headers if such functionality is necessary, ensuring that only known, trusted sources can utilize these specific endpoints. Additionally, enabling comprehensive logging mechanisms that capture all login attempts regardless of the User-Agent header value will help restore visibility into authentication events and aid in future incident response efforts. Long-term remediation requires refactoring the authentication logic to rely on server-side session tokens, IP reputation checks, or shared secrets rather than mutable HTTP headers for determining security policy application.