WWBN AVideo CVE-2026-41055

Exploitation requires the AVideo LiveLinks plugin to be enabled and its proxy.php endpoint reachable, and the attacker must control a domain's authoritative DNS to serve a rebinding response (safe external IP on first resolution, internal IP on the second) with TTL=0 to win the race between isSSRFSafeURL() validation and the get_headers()/fakeBrowser() request; alternatively the attacker crafts a response with multiple Location headers to trigger the filter_var() array fall-through. No user authentication is required (CVSS PR:N) and no victim interaction is needed, but exploitation is limited by the need for attacker-controlled rebinding DNS infrastructure and precise timing, and by network egress restrictions on the server - impact is information disclosure/internal probing (C:H, I:N/A:N), not code execution.

The published CVSS 3.1 vector (AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:N/A:N, base 8.6) frames this as easily exploitable and network-reachable with a scope change and high confidentiality impact, which is consistent with SSRF reaching internal networks. However, the exploitation mechanism - DNS rebinding requiring an attacker-controlled domain with TTL=0 and winning the race between two independent DNS resolutions - realistically implies higher attack complexity than AC:L suggests; defenders should treat the AC:L rating with caution. Corroborating signals are mixed: SSVC reports Exploitation=poc, Automatable=yes, Technical Impact=partial, and a working PoC is published, yet EPSS is very low (0.03%, 9th percentile) and there is no CISA KEV listing, indicating no confirmed active exploitation. Net assessment: a genuine, demonstrable SSRF worth patching, but the practical bar (rebinding infrastructure and timing) and info-disclosure-only impact place it below drop-everything urgency absent evidence of in-the-wild use.

An attacker registers a domain whose authoritative DNS answers with TTL=0, submits that domain as a live link to AVideo's proxy.php, and has it resolve to a benign public IP during isSSRFSafeURL() validation. When get_headers()/fakeBrowser() re-resolves the same name for the real request, the DNS server returns an internal address (e.g., 127.0.0.1 or 169.254.169.254), causing the server to fetch and disclose internal service or cloud-metadata responses. A public Python PoC demonstrating this rebinding sequence is included in the GHSA advisory.