CVE-2026-84476 in AVideoinfo

Summary

by MITRE • 09/02/2026

WWBN AVideo fails to validate trusted proxies before accepting X-Real-IP and X-Forwarded-For headers, allowing attackers to spoof the client address used by enforceRateLimit(). Attackers can rotate the header value per request to bypass login rate limiting and perform unlimited credential guessing attacks.

Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.

Analysis

by VulDB Data Team • 09/02/2026

The vulnerability in WWBN AVideo represents a critical failure in input validation regarding HTTP proxy headers, specifically targeting the X-Real-IP and X-Forwarded-For fields. These headers are commonly used by reverse proxies and load balancers to convey the original client IP address when traffic is routed through intermediate servers. However, the application fails to verify whether these requests originate from a trusted internal proxy or if they are arriving directly from an external network source. This lack of validation allows any remote attacker to inject arbitrary values into these headers, effectively manipulating how the server identifies the requester's identity for security enforcement mechanisms.

The core technical flaw lies in the improper handling of IP address trust boundaries within the application logic. By accepting unvalidated proxy headers as authoritative sources of truth for client identification, the software creates a direct path for Identity Manipulation. This misconfiguration undermines the integrity of access control systems that rely on accurate source IP addresses to enforce security policies. The vulnerability is classified under CWE-287, which covers Improper Authentication, and more specifically aligns with CWE-918 regarding Server-Side Request Forgery (SSRF) principles where trust in external data leads to unintended behavior. In the context of the MITRE ATT&CK framework, this technique corresponds to T1652 Impersonate Access Token or generally falls under Initial Access and Credential Access tactics by allowing attackers to bypass authentication controls through IP spoofing.

The operational impact of this vulnerability is severe, particularly concerning rate limiting mechanisms such as enforceRateLimit(). Rate limiting is a fundamental defense against brute-force attacks, designed to restrict the number of login attempts allowed from a single source within a specific time window. Because an attacker can rotate the X-Real-IP and X-Forwarded-For header values with each request, they can make it appear that every attempt originates from a different unique IP address. This technique effectively neutralizes the rate limiter's ability to detect and block repetitive malicious activity. Consequently, attackers are able to perform unlimited credential guessing attacks against user accounts without triggering alerts or receiving temporary bans, significantly increasing the success probability of brute-force campaigns targeting weak passwords or exposed administrative interfaces.

To mitigate this vulnerability, immediate configuration changes are required on both the web server and the application level. The most effective mitigation involves configuring the reverse proxy (such as Nginx, Apache, or HAProxy) to strip X-Real-IP and X-Forwarded-For headers from incoming requests before they reach the AVideo backend, ensuring that only trusted internal proxies can append these values securely via a separate mechanism like a custom header. Alternatively, if direct access is not possible, the application must be patched to strictly validate that incoming connections originate from known proxy IP ranges defined in a whitelist configuration file. This ensures that any request containing spoofed headers from untrusted external sources is either rejected or ignored for authentication purposes. Regular security audits and penetration testing should also be conducted to verify that no other endpoints within the AVideo ecosystem are susceptible to similar header injection flaws, ensuring comprehensive protection against IP-based bypass techniques.

Responsible

VulnCheck

Reservation

09/01/2026

Disclosure

09/02/2026

Moderation

accepted

CPE

ready

EPSS

0.00000

KEV

no

Activities

very low

Sources

Do you want to use VulDB in your project?

Use the official API to access entries easily!