Public March 2026
AVideo Revalidated the First URL but Not the Redirect Target
BugBunny.ai discovered that AVideo’s LiveLinks proxy applied SSRF validation only to the initial URL supplied by the attacker. Once that URL returned a redirect, AVideo fetched the Location target without repeating the SSRF check, allowing unauthenticated access to internal services and cloud metadata endpoints.
TL;DR
Remote attackers can use AVideo as an SSRF proxy to read internal HTTP services and cloud instance metadata.
Attacker-controlled URLs that return redirects to internal IPs, localhost services, or metadata endpoints.
AVideo releases before 24.0 through plugin/LiveLinks/proxy.php.
Published and fixed in AVideo 24.0.
Root Cause
The endpoint called isSSRFSafeURL() on the original livelink parameter but then trusted the redirect target returned by get_headers(). That broke the security model at the exact point where attacker-controlled routing changed destinations.
The subsequent fakeBrowser() call performed a raw fetch with no SSRF protections of its own, so the redirect bypass turned a partial validation scheme into a full unauthenticated SSRF primitive. In cloud environments that can expose metadata, temporary credentials, and internal network topology.
Product
AVideo
Affected
< 24.0
Patched
>= 24.0
Weaknesses
CWE-918: Server-Side Request Forgery (SSRF)
Mitigation
- Upgrade AVideo to version 24.0 or later.
- Re-validate every redirect target before fetching it.
- Disable automatic redirect following in helper functions that proxy attacker-supplied URLs.
Credits & Disclosure
Published via GitHub Security Advisory GHSA-9x67-f2v7-63rw for WWBN/AVideo on March 16, 2026.