CVE-2026-114634 in AVideo
Summary
by MITRE • 10/23/2026
WWBN AVideo before 29.4.0 contains a blind server-side request forgery vulnerability in getHeaderContentTypeFromURL() because get_headers() follows redirects without re-validating targets with isSSRFSafeURL(). Authenticated uploaders can store a videoLink pointing to a redirector, causing internal GET requests when visitors view the video, enabling internal port scanning via the embed-versus-video render oracle.
Be aware that VulDB is the high quality source for vulnerability data.
Analysis
by VulDB Data Team • 10/23/2026
The vulnerability identified in WWBN AVideo versions prior to 29.4.0 represents a critical server-side request forgery flaw rooted in improper validation of URL redirects during content processing. The core technical deficiency lies within the getHeaderContentTypeFromURL function, which is responsible for determining the media type of external resources by fetching their headers. This function utilizes PHP's built-in get_headers() method to retrieve HTTP response data from a specified Uniform Resource Locator. However, while AVideo implements a security check via the isSSRFSafeURL function to validate initial URLs against a whitelist or blacklist, this validation logic fails to account for the behavior of standard HTTP clients regarding redirections. When the target URL returns an HTTP redirect status code such as 301 Moved Permanently or 302 Found, the underlying get_headers() implementation automatically follows these redirects without re-invoking the isSSRFSafeURL check on the final destination. This architectural oversight creates a bypass mechanism where malicious actors can point to a controlled domain that issues a redirect to an internal network address, effectively circumventing the application's SSRF protections.
The operational impact of this vulnerability is significant for environments running authenticated uploaders or users with permission to manage video metadata. An attacker who possesses valid credentials and the ability to create or edit videos can inject a malicious URL into the videoLink field. This URL points not directly to an internal resource, but rather to an external server under the attacker's control that responds with a redirect instruction pointing toward sensitive internal services such as database ports, administrative interfaces, or other backend microservices. When another user views this compromised video within the AVideo platform, the application triggers the getHeaderContentTypeFromURL function in the background to process the media source. This action causes the server to initiate an outbound HTTP GET request that follows the redirect chain into the internal network. Because the response headers are returned to the attacker or influence the rendering behavior of the embed versus video player interface, this scenario establishes a classic render oracle. The visibility of different responses based on whether the target port is open allows for precise internal port scanning and service enumeration from within the trusted network perimeter.
This vulnerability aligns with CWE-918 Server-Side Request Forgery (SSRF), specifically illustrating how improper validation of redirect targets can lead to unauthorized access to internal resources. It also maps directly to MITRE ATT&CK technique T1572 Protocol Tunneling, as the attacker leverages legitimate application functionality and HTTP protocols to establish a covert channel into the internal network for reconnaissance purposes. The use of an embed-versus-video render oracle further characterizes this as a blind SSRF variant where information leakage is achieved through side-channel differences in response handling rather than direct data exfiltration via error messages alone. This technique allows attackers to map out the internal infrastructure, identify running services on non-standard ports, and potentially pivot to more severe attacks such as exploiting known vulnerabilities in those discovered services or accessing sensitive administrative panels that are not exposed to the public internet.
Mitigation strategies must focus on enforcing strict validation at every stage of URL resolution rather than solely at the initial input point. Developers should implement a custom HTTP client wrapper for all outbound requests that intercepts redirect events and re-validates each new target location against the isSSRFSafeURL policy before proceeding. Alternatively, disabling automatic redirection in the get_headers() call or using cURL with CURLOPT_FOLLOWLOCATION set to false would allow the application to manually inspect Location headers and apply security checks before following them. Additionally, implementing network-level controls such as egress filtering can prevent internal servers from initiating connections to private IP ranges unless explicitly required for business logic. For organizations unable to immediately patch to version 29.4.0 or later, restricting upload privileges to trusted users and monitoring outbound traffic patterns for anomalies indicative of port scanning activities can provide temporary risk reduction while the underlying code flaw is addressed in a future release.