CVE-2026-33039: WWBN AVideo SSRF Vulnerability

CVE-2026-33039 Overview

CVE-2026-33039 is a Server-Side Request Forgery (SSRF) vulnerability in WWBN AVideo, an open source video platform. The vulnerability exists in the plugin/LiveLinks/proxy.php endpoint where user-supplied URLs are validated against internal and private networks using the isSSRFSafeURL() function, but this validation only checks the initial URL. When the initial URL responds with an HTTP redirect (Location header), the redirect target is fetched via fakeBrowser() without re-validation, allowing an attacker to reach internal services through an attacker-controlled redirect.

Critical Impact

Unauthenticated attackers can bypass SSRF protections to access internal services including cloud metadata endpoints and RFC1918 private network addresses, potentially exposing sensitive configuration data, credentials, and internal infrastructure.

Affected Products

• WWBN AVideo versions 25.0 and below
• AVideo installations using the LiveLinks plugin with proxy functionality
• Self-hosted AVideo instances with network access to internal services

Discovery Timeline

• 2026-03-20 - CVE-2026-33039 published to NVD
• 2026-03-23 - Last updated in NVD database

Technical Details for CVE-2026-33039

Vulnerability Analysis

This SSRF vulnerability exploits a time-of-check time-of-use (TOCTOU) weakness in the URL validation logic. The isSSRFSafeURL() function performs security checks on the initial user-supplied URL to prevent access to internal networks, localhost, and cloud metadata endpoints. However, the implementation fails to account for HTTP redirects.

When an attacker provides a URL to an external server they control, the initial validation passes because the URL points to a legitimate external resource. The attacker's server then responds with an HTTP 302 redirect pointing to an internal resource such as http://169.254.169.254/latest/meta-data/ (AWS metadata) or RFC1918 addresses like http://192.168.1.1/. The fakeBrowser() function follows this redirect without re-validating the destination URL against the SSRF protection rules.

This bypass technique allows complete circumvention of the intended security controls, enabling attackers to probe internal network infrastructure, access cloud provider metadata services, and potentially retrieve sensitive information including API keys, credentials, and infrastructure details.

Root Cause

The root cause is insufficient validation during HTTP redirect handling. The isSSRFSafeURL() function implements SSRF protections but is only invoked for the initial URL supplied by the user. The fakeBrowser() function, which handles the actual HTTP request including redirect following, does not invoke the same validation checks on redirect destinations. This creates a security gap where validated initial URLs can redirect to restricted internal resources.

Attack Vector

The attack is network-based and requires no authentication or user interaction. An attacker sets up a malicious web server that responds to requests with HTTP 302 redirects pointing to internal targets. By submitting a URL to their malicious server through the plugin/LiveLinks/proxy.php endpoint, the attacker can:

1. Bypass the initial SSRF validation with an external URL
2. Have their server respond with a redirect to an internal target
3. Cause the AVideo server to fetch the internal resource
4. Receive the response containing potentially sensitive internal data

The vulnerability can be exploited to access cloud metadata services (AWS, GCP, Azure), internal web applications, databases listening on private interfaces, and other services only accessible from the internal network.

Detection Methods for CVE-2026-33039

Indicators of Compromise

• Suspicious requests to plugin/LiveLinks/proxy.php with external URLs that may serve as redirect pivots
• Outbound connections from the AVideo server to cloud metadata endpoints (169.254.169.254, 169.254.170.2)
• Access logs showing requests to the proxy endpoint followed by internal network connections
• Unexpected traffic from the web server to RFC1918 address ranges (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16)

Detection Strategies

• Monitor web server access logs for requests to plugin/LiveLinks/proxy.php with unusual or suspicious URL parameters
• Implement network-level monitoring for outbound connections from web servers to metadata service IPs
• Deploy web application firewall (WAF) rules to detect and block SSRF patterns in URL parameters
• Review server-side logs for redirect chains that terminate at internal addresses

Monitoring Recommendations

• Enable verbose logging on the AVideo application to capture full request details including redirect chains
• Configure network segmentation alerts for unexpected cross-segment traffic originating from the web tier
• Implement egress filtering to restrict which internal resources web application servers can access
• Monitor for reconnaissance patterns such as sequential scanning of internal IP ranges through the proxy endpoint

How to Mitigate CVE-2026-33039

Immediate Actions Required

• Upgrade WWBN AVideo to version 26.0 or later immediately
• If immediate upgrade is not possible, disable or restrict access to the plugin/LiveLinks/proxy.php endpoint
• Implement network segmentation to limit the AVideo server's access to internal resources
• Deploy WAF rules to block requests containing internal IP addresses or metadata service URLs in redirect responses

Patch Information

The vulnerability has been fixed in AVideo version 26.0. The fix ensures that URL validation is performed not only on the initial user-supplied URL but also on all redirect destinations before following them. The patch commit (0e56382921fc71e64829cd1ec35f04e338c70917) modifies the redirect handling logic to re-validate each URL in the redirect chain against the SSRF protection rules.

For detailed information about the security fix, refer to the GitHub Security Advisory GHSA-9x67-f2v7-63rw and the commit changes.

Workarounds

• Disable the LiveLinks plugin entirely if not required for business operations
• Implement network-level egress filtering to prevent the web server from connecting to internal networks and cloud metadata services
• Use a reverse proxy or WAF to inspect and block responses containing redirects to internal addresses
• Restrict access to the proxy.php endpoint to authenticated users only through web server configuration

# Apache configuration to restrict access to the vulnerable endpoint
<Location "/plugin/LiveLinks/proxy.php">
    # Deny all access until patched
    Require all denied
    
    # Or restrict to authenticated administrators only
    # Require user admin
</Location>