AVideo-Encoder EUVD-2026-112512

Exploitable against default configurations of AVideo-Encoder: the only destination gate, Streamer::isURLAllowed, permits all targets when the operator allowlist is empty, which is the default, and Login::isLogged re-authenticates from the attacker-settable encoder_aVideoURL cookie plus arbitrary nonempty encoder_user/encoder_pass cookies, so no account or operator interaction is needed. No special feature must be enabled for the core SSRF; TLS peer verification is disabled, so untrusted self-signed HTTPS certificates on internal targets are accepted. Limiting factors: the attacker must have network reachability to the encoder; full credential theft via the metadata path requires the encoder to run in a cloud environment with a reachable instance-metadata service (e.g. 169.254.169.254); the FTP variant additionally requires an ftp-scheme videoURL routed through view/youtubeDl.json.php; and if an operator has populated a non-empty allowlist, destinations are restricted to allowed sites. On 8.1.0 the raw-response reflection is removed, but private-network exemptions and login TLS-verification defaults still leave the internal-network and TLS variants exploitable.

All provided signals point to a genuine, actionable priority rather than an inflated CVSS number. The CVSS vector (AV:N/AC:L/PR:N/UI:N) is corroborated by the GHSA advisory and the PoC: exploitation is network-reachable, low-complexity, unauthenticated (PR:N), and needs no user interaction, because Login::isLogged re-authenticates from attacker-settable cookies and Streamer::isURLAllowed returns true when the operator allowlist is empty - the default state. The vuln.today decision label is 'this_week', consistent with a serious but not emergency-grade issue; there is no CISA KEV entry in the input, so active exploitation is not confirmed, and no EPSS score is provided, so widespread-exploitation probability cannot be quantified from the data given. A documented PoC exists in the GHSA advisory (working curl requests demonstrating credential exfiltration), which raises practical risk above a theoretical SSRF. The most important nuance is a patch-signal conflict: the multi-source input says a patch is 'Available from vendor' (v8.1.0), but the description and GHSA both state 8.1.0 is only an initial remediation attempt and the GHSA package record says 'fixed in: not yet patched' - so 'patch available' overstates the remediation status, and defenders should treat the private-network and TLS-verification variants as unresolved. Net: a real, high-severity unauthenticated SSRF with credential-theft impact meriting prompt action this week, with the caveat that the advertised fix is incomplete.

An unauthenticated attacker who can reach the encoder sends a request carrying an attacker-set encoder_aVideoURL cookie (or a siteURL/videoURL field) pointing at an internal address such as the cloud instance-metadata endpoint 169.254.169.254; the encoder fetches it from its own network position and reflects the raw body back in the login response's result field, handing the attacker IAM role credentials. The GHSA advisory includes a working proof-of-concept (curl requests) demonstrating the cookie SSRF, disabled-TLS exploitation, internal TCP/port reach, and the pre-auth FTP variant. Because the vector is AV:N/AC:L/PR:N/UI:N against the default empty-allowlist configuration, no account, operator interaction, or complex conditions are required.