CVE-2026-33480: Wwbn Avideo SSRF Vulnerability

CVE-2026-33480 Overview

WWBN AVideo is an open source video platform. In versions up to and including 26.0, the isSSRFSafeURL() function in AVideo can be bypassed using IPv4-mapped IPv6 addresses (::ffff:x.x.x.x). The unauthenticated plugin/LiveLinks/proxy.php endpoint uses this function to validate URLs before fetching them with curl, but the IPv4-mapped IPv6 prefix passes all checks, allowing an attacker to access cloud metadata services, internal networks, and localhost services.

Critical Impact

Unauthenticated attackers can bypass SSRF protections to access internal network resources, cloud metadata services (AWS/GCP/Azure), and localhost services, potentially exposing sensitive credentials and configuration data.

Affected Products

• WWBN AVideo versions up to and including 26.0
• All installations using the plugin/LiveLinks/proxy.php endpoint
• Self-hosted AVideo deployments with access to internal networks or cloud metadata services

Discovery Timeline

• 2026-03-23 - CVE-2026-33480 published to NVD
• 2026-03-24 - Last updated in NVD database

Technical Details for CVE-2026-33480

Vulnerability Analysis

This Server-Side Request Forgery (SSRF) vulnerability (CWE-918) exists in the URL validation logic of WWBN AVideo's isSSRFSafeURL() function located in objects/functions.php. The function was designed to prevent SSRF attacks by blocking requests to private and reserved IP ranges. However, the implementation relied on regex-based pattern matching for IPv4 addresses (10.x.x.x, 172.16-31.x.x, 192.168.x.x) without accounting for IPv4-mapped IPv6 address notation.

IPv4-mapped IPv6 addresses follow the format ::ffff:x.x.x.x, where the IPv4 address is embedded within an IPv6 representation. When an attacker supplies a URL like http://[::ffff:169.254.169.254]/latest/meta-data/, the existing regex patterns fail to match because they only check for pure IPv4 dotted-decimal notation. This allows the crafted address to bypass all private IP range checks while still resolving to the intended internal target.

The vulnerable endpoint plugin/LiveLinks/proxy.php accepts URL parameters without authentication, passes them through the flawed isSSRFSafeURL() validation, and then uses curl to fetch the resource. This creates a direct pathway for attackers to reach internal services, including cloud provider metadata endpoints that often contain IAM credentials, API tokens, and instance configuration data.

Root Cause

The root cause is incomplete input validation in the isSSRFSafeURL() function. The original implementation used manual regex patterns to block private IPv4 ranges but failed to normalize IPv4-mapped IPv6 addresses to their equivalent IPv4 form before validation. This oversight allowed the ::ffff: prefix to act as a bypass mechanism, as the dotted-decimal regex patterns cannot match the embedded IPv4 portion of the mapped address format.

Attack Vector

An attacker can exploit this vulnerability by sending an unauthenticated HTTP request to the plugin/LiveLinks/proxy.php endpoint with a specially crafted URL parameter. By using IPv4-mapped IPv6 notation such as ::ffff:127.0.0.1 or ::ffff:169.254.169.254, the attacker bypasses the SSRF protection and forces the server to make requests to internal resources. This enables access to cloud metadata services, internal APIs, administrative interfaces, and any service accessible from the server's network position.

The following code shows the security patch that addresses this vulnerability by normalizing IPv4-mapped IPv6 addresses before validation:

         return false;
     }
 
-    // Block private IPv4 ranges
-    // 10.0.0.0 - 10.255.255.255
-    if (preg_match('/^10\.\d{1,3}\.\d{1,3}\.\d{1,3}$/', $ip)) {
-        _error_log("isSSRFSafeURL: blocked private IP (10.x.x.x): {$ip}");
+    // Normalize IPv4-mapped IPv6 addresses (::ffff:x.x.x.x) to their plain IPv4 form.
+    // Without this, dotted-decimal private-range regexes and PHP's FILTER_FLAG_NO_PRIV_RANGE
+    // flag both miss the mapped address — the bypass vector reported in CVE-class SSRF findings.
+    if (preg_match('/^::ffff:(\d{1,3}\.\d{1,3}\.\d{1,3}\.\d{1,3})$/i', $ip, $mapped)) {
+        _error_log("isSSRFSafeURL: normalized IPv4-mapped IPv6 {$ip} to {$mapped[1]}");
+        $ip = $mapped[1];
+    }
+
+    // Block all private and reserved IP ranges using PHP's built-in validation flags.
+    // FILTER_FLAG_NO_PRIV_RANGE rejects: RFC 1918 (10/8, 172.16/12, 192.168/16), fc00::/7
+    // FILTER_FLAG_NO_RES_RANGE rejects: 0/8, 127/8, 169.254/16, ::1, fe80::/10, and others
+    // This replaces the previous manual regex checks and the separate IPv6 block section.
+    if (!filter_var($ip, FILTER_VALIDATE_IP, FILTER_FLAG_NO_PRIV_RANGE | FILTER_FLAG_NO_RES_RANGE)) {
+        _error_log("isSSRFSafeURL: blocked private/reserved IP: {$ip}");
         return false;
     }
 
-    // 172.16.0.0 - 172.31.255.255
-    if (preg_match('/^172\.(1[6-9]|2\d|3[0-1])\.\d{1,3}\.\d{1,3}$/', $ip)) {
-        _error_log("isSSRFSafeURL: blocked private IP (172.16-31.x.x): {$ip}");
-        return false;
-    }
-

Source: GitHub Commit Details

Detection Methods for CVE-2026-33480

Indicators of Compromise

• HTTP requests to /plugin/LiveLinks/proxy.php containing URL parameters with IPv6 notation (::ffff: prefix)
• Outbound requests from the AVideo server to internal IP ranges (127.0.0.1, 10.x.x.x, 169.254.169.254)
• Unusual access patterns to cloud metadata endpoints from web application processes
• Log entries in AVideo containing IPv4-mapped IPv6 addresses

Detection Strategies

• Deploy web application firewall (WAF) rules to detect and block requests containing ::ffff: patterns in URL parameters
• Monitor outbound network connections from the AVideo server for requests to private IP ranges and cloud metadata services
• Implement network segmentation alerts for unexpected traffic from web servers to internal infrastructure
• Review access logs for the proxy.php endpoint with anomalous URL patterns

Monitoring Recommendations

• Enable verbose logging in AVideo to capture SSRF validation attempts via _error_log() entries
• Configure network intrusion detection systems to alert on metadata service access (169.254.169.254)
• Monitor for unusual curl or HTTP client activity originating from the AVideo process
• Set up alerting for outbound connections from web servers to RFC 1918 address ranges

How to Mitigate CVE-2026-33480

Immediate Actions Required

• Update WWBN AVideo to the latest version containing commit 75ce8a579a58c9d4c7aafe453fbced002cb8f373
• If immediate patching is not possible, disable or restrict access to the plugin/LiveLinks/proxy.php endpoint
• Implement network-level controls to block outbound requests from the AVideo server to cloud metadata services
• Review logs for any prior exploitation attempts using IPv4-mapped IPv6 addresses

Patch Information

The vulnerability has been addressed in commit 75ce8a579a58c9d4c7aafe453fbced002cb8f373. The patch normalizes IPv4-mapped IPv6 addresses to their plain IPv4 form before validation and replaces manual regex checks with PHP's built-in filter_var() function using FILTER_FLAG_NO_PRIV_RANGE and FILTER_FLAG_NO_RES_RANGE flags. Organizations should apply this patch immediately or upgrade to a version that includes this fix. For more details, see the GitHub Security Advisory GHSA-p3gr-g84w-g8hh.

Workarounds

• Restrict network access from the AVideo server using firewall rules to block connections to internal networks and cloud metadata services
• Disable the LiveLinks plugin if not required for business operations
• Place the AVideo server in an isolated network segment with no access to internal resources
• Use a reverse proxy with SSRF-aware filtering to validate outbound requests before they reach the application

# Example iptables rules to block outbound SSRF targets from AVideo server
# Block cloud metadata services
iptables -A OUTPUT -d 169.254.169.254 -j DROP

# Block private IP ranges
iptables -A OUTPUT -d 10.0.0.0/8 -j DROP
iptables -A OUTPUT -d 172.16.0.0/12 -j DROP
iptables -A OUTPUT -d 192.168.0.0/16 -j DROP
iptables -A OUTPUT -d 127.0.0.0/8 -j DROP