Description

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.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "7.5",
  "pubDate": "2026-09-01T23:17:21.670Z",
  "pubdate": "2026-09-01T23:17:21.670Z",
  "executiveSummary": "The vulnerability resides in the WWBN AVideo platform, specifically concerning the improper handling of HTTP headers used for client identification. The application fails to perform adequate validation of trusted proxies when processing X-Real-IP and X-Forwarded-For headers, leading to an IP spoofing vulnerability. This flaw allows unauthorized actors to manipulate the source IP address perceived by the application, effectively bypassing security controls dependent on client origin.\nThe primary impact of this vulnerability is the subversion of the enforceRateLimit() function. By rotating the values provided in these headers, an attacker can circumvent login rate-limiting mechanisms, facilitating high-frequency, automated credential guessing or brute-force attacks against administrative or user accounts. This significantly increases the risk of unauthorized account access and potential platform compromise. The vulnerability does not require prior authentication, and exploitation is straightforward, requiring only the ability to send manipulated HTTP requests to the target server.",
  "technicalDetails": "The root cause of this vulnerability is the implicit trust placed in client-supplied HTTP headers—specifically X-Real-IP and X-Forwarded-For—without verifying that the request originated from a legitimate, pre-configured trusted proxy server. In modern web architectures, these headers are standard for identifying the client's original IP address when passing through load balancers or reverse proxies. However, AVideo accepts these headers globally without checking the source network context, allowing any external actor to inject arbitrary IP addresses.\nThe vulnerability directly affects the internal logic of the enforceRateLimit() function. This function is designed to mitigate brute-force attempts by tracking the number of requests associated with a specific IP address within a predefined time window. When an attacker sends a login request, the application retrieves the IP address from the unverified X-Forwarded-For or X-Real-IP header rather than the actual connection socket address. By modifying these headers in each subsequent request, the attacker ensures that every attempt appears to originate from a unique, non-blocked IP address.\nThe attack flow follows a deterministic process: 1. The attacker initiates a series of authentication requests against the AVideo login endpoint. 2. For each request, the attacker modifies the X-Forwarded-For or X-Real-IP header to contain a randomized or sequential IP address. 3. The server-side enforceRateLimit() function processes the request, interprets the spoofed IP address as the genuine source, and updates its rate-limiting counter for that specific spoofed address. 4. Because each request utilizes a unique header value, the threshold for rate limiting is never triggered for any single IP, effectively rendering the protection mechanism null.\nThis vulnerability is critical because it removes the technical barrier to large-scale credential stuffing or brute-force campaigns. An attacker can perform a massive number of login attempts without risk of being blocked, significantly increasing the probability of successfully guessing legitimate user credentials. There is no requirement for high-privilege access to initiate this, as the attack is external and network-facing. The impact includes account takeover, credential exposure, and potential bypass of other IP-based security filters implemented within the AVideo environment."
}