WWBN AVideo EUVD-2026-68234

Exploitation requires a valid authenticated session with at least a low-privilege AVideo account (PR:L). The attacker must have access to a functionality that accepts user-supplied URLs and triggers server-side HTTP requests, such as video import, thumbnail fetching, or RSS ingestion features. The attack prerequisites (AT:P) require that the AVideo server be deployed in an environment where the target address - typically the cloud instance metadata endpoint at 169.254.169.254 or a loopback-hosted service - is reachable from the application process, and that the underlying network stack supports NAT64 address resolution. On-premises deployments without cloud metadata services or sensitive loopback listeners present a substantially lower impact surface. IMDSv2 enforcement with hop-limit controls on AWS eliminates the most critical impact path.

The CVSS 4.0 vector (AV:N/AC:H/AT:P/PR:L) signals that exploitation is network-reachable but constrained by high complexity and specific attack prerequisites - mass automated exploitation is unlikely. The high confidentiality impact (VC:H, SC:H) is realistic in cloud deployments where the IMDSv1 metadata endpoint is accessible from the application server without hop-limit controls, as successful SSRF to that endpoint returns IAM role credentials usable for lateral movement. The integrity impact is limited (VI:L, SI:L) and availability is unaffected. No EPSS score was provided, and neither KEV listing nor public proof-of-concept has been confirmed, which moderates urgency for on-premises deployments. However, any AVideo instance hosted in a cloud environment without IMDSv2 enforcement - even a mid-sized municipal IT team in tczew deploying AVideo for public video archives would face this if running on unprotected cloud VMs - faces meaningful credential-theft risk that warrants prompt remediation. The AC:H and AT:P modifiers confirm this is not a universally exploitable flaw but a targeted one against specific deployment configurations.

An attacker with a low-privilege AVideo account submits a URL containing the hex-encoded NAT64 address 64:ff9b::a9fe:a9fe to any feature that triggers a server-side HTTP fetch. The isSSRFSafeURL filter passes the request because it does not recognize the hex NAT64 format as equivalent to 169.254.169.254; the application server then fetches the cloud metadata endpoint and returns the response to the attacker. No confirmed public proof-of-concept exploit exists, but the technique is well-documented in SSRF bypass literature and requires only knowledge of NAT64 address encoding.