CVE-2026-33766 Overview
CVE-2026-33766 is a Server-Side Request Forgery (SSRF) bypass vulnerability affecting WWBN AVideo, an open source video platform. The vulnerability exists in versions up to and including 26.0, where the isSSRFSafeURL() function validates URLs against private and reserved IP ranges before fetching, but the url_get_contents() function follows HTTP redirects without re-validating the redirect target. This allows an attacker to bypass SSRF protection by redirecting from a public URL to an internal target.
Critical Impact
An attacker can access internal network resources, cloud metadata endpoints (e.g., 169.254.169.254), and other protected services by exploiting the redirect-following behavior to bypass URL validation checks.
Affected Products
- WWBN AVideo versions up to and including 26.0
Discovery Timeline
- 2026-03-27 - CVE CVE-2026-33766 published to NVD
- 2026-03-31 - Last updated in NVD database
Technical Details for CVE-2026-33766
Vulnerability Analysis
This vulnerability is classified under CWE-918 (Server-Side Request Forgery). The core issue stems from a time-of-check time-of-use (TOCTOU) gap in the URL validation workflow. The AVideo platform implements SSRF protection through the isSSRFSafeURL() function, which correctly validates that a provided URL does not point to internal or private IP addresses. However, this validation only occurs once—before the initial request is made.
When url_get_contents() or the wget function makes the HTTP request, PHP's default behavior automatically follows HTTP redirects (3xx responses). If the initial URL passes validation but redirects to an internal address, the follow-up request bypasses all security checks. This allows attackers to reach sensitive internal endpoints that should be protected.
Root Cause
The root cause is the separation between URL validation and URL fetching logic. The isSSRFSafeURL() function validates URLs against blacklisted IP ranges (private networks, localhost, cloud metadata endpoints), but when HTTP context options allow automatic redirect following (follow_location enabled by default), the subsequent redirect targets are never validated. This architectural flaw means any URL that initially points to a public server can redirect to protected internal resources.
Attack Vector
The attack is network-based and requires no authentication. An attacker crafts a URL pointing to an attacker-controlled server that returns an HTTP redirect (301, 302, etc.) to an internal target. When a victim platform feature fetches the malicious URL:
- The attacker's URL (e.g., https://attacker.com/redirect) passes isSSRFSafeURL() validation
- The AVideo server makes a request to the attacker's URL
- The attacker's server responds with a redirect to an internal address (e.g., http://169.254.169.254/latest/meta-data/)
- PHP automatically follows the redirect without re-validation
- The attacker receives the response from the internal resource
// Vulnerable code - HTTP context allows redirect following
$opts = [
'http' => ['header' => "User-Agent: {$agent}\r\n"],
// follow_location defaults to 1 (enabled), allowing SSRF bypass
'ssl' => [
'verify_peer' => false,
'verify_peer_name' => false,
]
];
Source: GitHub Commit Update
Detection Methods for CVE-2026-33766
Indicators of Compromise
- Outbound HTTP requests from the AVideo server to external URLs that subsequently access internal IP ranges (10.x.x.x, 172.16-31.x.x, 192.168.x.x)
- Access logs showing requests to cloud metadata endpoints (169.254.169.254) originating from the web application
- Suspicious URL patterns in user-submitted content containing redirect services or attacker-controlled domains
- Network traffic showing 3xx redirect responses from external servers redirecting to internal addresses
Detection Strategies
- Monitor web application firewall (WAF) logs for SSRF patterns and redirect chains
- Implement network segmentation alerts when the web server attempts connections to internal infrastructure
- Deploy egress filtering with logging to detect unauthorized internal network access from the DMZ
- Analyze AVideo access logs for URL parameters containing known redirect service patterns
Monitoring Recommendations
- Configure network monitoring to alert on connections from web servers to RFC 1918 addresses or link-local addresses
- Enable verbose logging for URL fetching functions in the AVideo application
- Monitor DNS queries from the AVideo server for internal hostname resolution attempts
- Implement cloud provider metadata endpoint access logging if running in AWS, GCP, or Azure environments
How to Mitigate CVE-2026-33766
Immediate Actions Required
- Update WWBN AVideo to a version containing commit 8b7e9dad359d5fac69e0cbbb370250e0b284bc12 or later
- If immediate patching is not possible, implement network-level egress filtering to block the web server from accessing internal IP ranges
- Review and audit any functionality that accepts URLs from user input
- Consider placing the AVideo instance behind a WAF with SSRF protection rules
Patch Information
The vulnerability has been addressed in commit 8b7e9dad359d5fac69e0cbbb370250e0b284bc12. The fix modifies both objects/functions.php and objects/functionsExec.php to disable automatic HTTP redirect following by setting follow_location to 0 in the stream context. This forces manual handling of redirects, allowing each redirect target to be validated through isSSRFSafeURL() before following.
For full details, see the GitHub Security Advisory and the patch commit.
Workarounds
- Implement network-level egress filtering to prevent the AVideo server from initiating connections to internal networks
- Deploy a reverse proxy that strips or blocks redirect responses pointing to internal addresses
- Configure firewall rules to block outbound traffic from the web server to metadata endpoints (169.254.169.254)
- Temporarily disable features that accept user-supplied URLs for content fetching
// Patched code - disables automatic redirect following
$opts = [
'http' => [
'header' => "User-Agent: {$agent}\r\n",
// SECURITY: Disable PHP's automatic HTTP redirect following.
// Set follow_location = 0 so PHP stops at every redirect and hands
// control back to us. We then re-check each redirect target ourselves
// with isSSRFSafeURL() before deciding whether to follow it.
'follow_location' => 0,
],
'ssl' => [
'verify_peer' => false,
'verify_peer_name' => false,
]
];
Source: GitHub Commit Update
Disclaimer: This content was generated using AI. While we strive for accuracy, please verify critical information with official sources.


