CVE-2026-33690: IP Address Spoofing via Unsafe Header Processing in WWBN AVideo

WWBN AVideo is an open-source video platform widely deployed for hosting and streaming multimedia content. In versions up to and including 26.0, the application suffers from an IP address spoofing vulnerability due to improper input validation. The vulnerability is tracked as CVE-2026-33690 and originates from a flawed implementation of client IP address resolution within the application core.

The underlying issue represents a classic instance of CWE-348: Use of Less Trusted Source. The application logic trusts user-controlled HTTP headers to determine the origin IP address rather than relying on the authoritative TCP socket connection data. This design flaw allows remote, unauthenticated attackers to manipulate their perceived network location by injecting specific HTTP headers into their requests.

The resulting impact includes the bypass of IP-based access controls, circumvention of rate limiting mechanisms, and the corruption of audit logs. Attackers can leverage this vulnerability to access restricted administrative interfaces or bypass Distributed Denial of Service (DDoS) protections. A patch was introduced in commit 1a1df6a9377e5cc67d1d0ac8ef571f7abbffbc6c, which implements a conditional trust model for header evaluation.

The vulnerability stems from the getRealIpAddr() function located in objects/functions.php. This function serves as the central utility for resolving client IP addresses across the entire AVideo platform. Several critical security components rely on this function, including the Live plugin authorization mechanism (plugin/Live/authorizeKeyAccess.php) and the DDoS Captcha validation routine (view/ddosCaptcha.php).

In the vulnerable implementation, the function processes an array of HTTP headers in a predetermined sequence to extract the client IP. The prioritized headers include X-Real-IP, Client-IP, and X-Forwarded-For. The authoritative TCP connection address, stored in the REMOTE_ADDR server variable, is evaluated last.

Because HTTP headers are entirely user-controlled, any client can arbitrarily define the values for X-Real-IP or X-Forwarded-For. When an attacker sends a request containing these headers, the getRealIpAddr() function extracts the spoofed value and returns it to the calling function. The application then processes the request under the assumption that it originated from the spoofed address.

This architecture fundamentally violates the principle of zero trust. By deferring the identity check to mutable application-layer data instead of immutable transport-layer data, the application exposes its security controls to trivial manipulation. The system makes no effort to verify whether the incoming request traversed a trusted proxy before parsing the forwarded headers.

The pre-patch implementation of getRealIpAddr() relied on a loop that evaluated HTTP headers before falling back to the TCP socket address. If any of the target headers contained a value, the function parsed it and immediately returned the result.

The remediation introduced by Daniel Neto in commit 1a1df6a9377e5cc67d1d0ac8ef571f7abbffbc6c replaces this logic with a conditional trust model. The patch introduces a new validation function, isPrivateOrLoopbackIP(), which utilizes PHP's filter_var to determine if a given IP address belongs to an RFC1918 private range or a loopback interface.

function isPrivateOrLoopbackIP($ip)
{
    if (!filter_var($ip, FILTER_VALIDATE_IP)) {
        return false;
    }
 
    return !filter_var($ip, FILTER_VALIDATE_IP, FILTER_FLAG_NO_PRIV_RANGE | FILTER_FLAG_NO_RES_RANGE);
}

The refactored getRealIpAddr() function now retrieves the REMOTE_ADDR value first. It then passes this authoritative address to isPrivateOrLoopbackIP(). If the TCP connection originates from a public IP address, the function returns that address immediately and ignores all HTTP headers. If the connection originates from a private or loopback address, the application assumes it is operating behind a trusted reverse proxy and proceeds to parse the X-Forwarded-For or X-Real-IP headers.

While this implementation successfully mitigates the primary attack vector for internet-facing instances, it introduces residual risks in multi-tenant environments. The patch trusts any request originating from a private IP range. In shared Virtual Private Cloud (VPC) networks or multi-tenant Docker deployments, a malicious container operating on a distinct internal IP could still successfully spoof headers, as its source IP would satisfy the isPrivateOrLoopbackIP() condition.

Exploiting CVE-2026-33690 requires no specialized tooling beyond a standard HTTP client capable of modifying request headers. The attacker identifies an endpoint protected by IP-based access controls or rate limiting, such as the DDoS Captcha mechanism or specific administrative APIs.

The attacker crafts an HTTP request and injects a target IP address into the X-Forwarded-For or X-Real-IP header. For example, an attacker attempting to bypass a blocklist might supply a benign residential IP address. Conversely, an attacker attempting to access an internal administrative function might supply a loopback address (127.0.0.1) or a known internal subnet address.

GET /plugin/Live/authorizeKeyAccess.php HTTP/1.1
Host: target-avideo-instance.com
X-Forwarded-For: 127.0.0.1
User-Agent: Mozilla/5.0

Upon receiving the request, the web server passes the raw HTTP data to the PHP backend. The vulnerable getRealIpAddr() function encounters the X-Forwarded-For header, extracts 127.0.0.1, and returns it to the authorization module. The application evaluates the spoofed IP against its access control lists and grants the attacker unauthorized access to the endpoint.

The vulnerability carries a CVSS v3.1 base score of 5.3, reflecting a medium severity level. The scoring vector CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:N highlights that the attack requires no privileges, no user interaction, and possesses a low complexity of execution over a network.

The primary impact is a partial compromise of system integrity. Attackers can manipulate application-level audit logs by injecting arbitrary IP addresses, complicating incident response and forensic investigations. Security teams relying on AVideo access logs to track malicious activity will receive falsified telemetry data.

Furthermore, the vulnerability undermines availability protections. The platform's DDoS Captcha system utilizes client IP addresses to enforce rate limits and issue challenges. By rotating spoofed IP addresses across subsequent requests, an attacker can trivially exhaust application resources while circumventing the Captcha mechanism entirely.

The confidentiality impact is rated as none within the CVSS assessment, as IP spoofing alone does not directly expose sensitive data. However, if AVideo is deployed with plugins or custom modules that restrict sensitive functionality to specific IP addresses, this vulnerability could facilitate unauthorized data access as a secondary consequence.

The definitive resolution for CVE-2026-33690 requires upgrading WWBN AVideo to a version released subsequent to the March 23, 2026 patch. Administrators must verify that their deployment includes commit 1a1df6a9377e5cc67d1d0ac8ef571f7abbffbc6c within the core codebase.

For environments where immediate patching is not feasible, administrators must enforce strict HTTP header sanitization at the network edge. Reverse proxies such as Nginx, HAProxy, or Apache must be configured to strip incoming X-Forwarded-For, X-Real-IP, and Client-IP headers from all external client requests.

In Nginx, this can be achieved by overwriting the header value with the authoritative client IP address before forwarding the request to the upstream application. Example configurations should explicitly set proxy_set_header X-Forwarded-For $remote_addr; to ensure external clients cannot inject arbitrary addresses.

Finally, organizations operating AVideo within shared or multi-tenant network environments must implement network-level isolation. Because the patched application inherently trusts requests originating from any RFC1918 IP address, the deployment environment must guarantee that internal network routes are strictly controlled. Microsegmentation and strict firewall rules are required to prevent internal adversaries from exploiting the remaining trust boundary weaknesses.