CVE-2026-33766: SSRF in wwbn/avideo

The SSRF vulnerability in wwbn/avideo arises from a discrepancy between the validation and execution phases of URL handling. The isSSRFSafeURL() function attempts to validate URLs against private/reserved IP ranges before fetching content. However, the urlgetcontents() function, which uses filegetcontents() with default redirect following enabled, does not re-validate the redirect target. An attacker can exploit this by crafting a request that redirects from a publicly accessible URL to an internal resource, effectively bypassing the initial validation check. This could lead to unauthorized access to sensitive internal data, services, or even the execution of commands on internal systems if those services are vulnerable. The blast radius depends on the internal services accessible via SSRF.

1. Reserved2026-03-23
2. Published2026-03-26
3. Modified2026-04-08
4. EPSS updated2026-04-04

Given that a direct patch is not yet available, several mitigation strategies can be employed. First, implement a Web Application Firewall (WAF) or reverse proxy to filter out requests containing suspicious redirects. Configure the WAF to block requests with excessive redirects or those targeting internal IP addresses. Secondly, disable HTTP redirects within the urlgetcontents() function if possible, or implement custom redirect validation logic. Finally, carefully review and restrict the permissions of the user account running the wwbn/avideo application to minimize the potential impact of a successful SSRF attack. After implementing these mitigations, verify their effectiveness by attempting to trigger the SSRF vulnerability with a controlled redirect.

Last updated

29.0recently