WWBN AVideo CVE-2026-114634

Requires a valid authenticated account with the uploader role (PR:L) able to submit a video with an attacker-controlled videoLink URL, so instances that restrict uploading to trusted staff are far less exposed than those allowing open uploader self-registration. The attacker must control a redirector that first passes isSSRFSafeURL() on the initial URL and then 302-redirects to an internal target, since get_headers() follows the redirect without re-validating. Triggering the server-side request also requires a visitor (or the attacker) to view the stored video, and useful results depend on the server having network reachability to internal services; exploitation is blind, yielding only a port/service-reachability oracle rather than response contents. Affected: AVideo before 29.4.0.

This is a genuine but moderate-priority issue, not a top-tier emergency. The CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:L/UI:N) confirms network-reachable, low-complexity exploitation, but PR:L means a valid authenticated uploader account is required, which meaningfully narrows the attacker population to insiders or users of instances that allow self-registration of uploaders. The impact is constrained: this is a BLIND SSRF whose practical value is internal reconnaissance (port scanning) via an embed-versus-video render oracle, not direct data exfiltration or RCE, which is consistent with the medium 5.3 base score. No EPSS score was provided in the input, and there is no CISA KEV listing and no public exploit code referenced - exploitation status is 'no public exploit identified at time of analysis.' The signals are internally consistent (medium severity, authenticated, limited-impact SSRF), so there is no CVSS-versus-reality conflict to flag; the main caveat is that EPSS data is absent, so probabilistic exploitation likelihood could not be weighed. Overall: patch on a normal cadence, prioritizing multi-tenant or public-upload AVideo deployments where untrusted users hold uploader roles and where the server has network paths to sensitive internal services (metadata endpoints, admin panels).

An attacker with a low-privileged uploader account on an AVideo instance stores a video whose videoLink points to an attacker-controlled redirector. When any visitor views that video, the server calls getHeaderContentTypeFromURL(), and get_headers() follows the redirect to an internal host without re-validating it, issuing an internal GET request. By observing whether the content renders as an embed versus a native video, the attacker infers whether internal ports/services are reachable, scanning the internal network. No public exploit code is referenced, but the vendor patch commit and included test case fully illustrate the technique.