Description

AVideo before 24.0 contains a server-side request forgery vulnerability in the isSSRFSafeURL function that fails to extract embedded IPv4 addresses from NAT64, 6to4, and Teredo IPv6 transition address formats. Unauthenticated attackers can bypass SSRF protections via the LiveLinks proxy endpoint to reach internal services and cloud metadata endpoints by encoding private IPv4 targets in transition address formats.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "7.5",
  "pubDate": "2026-08-27T17:20:57.003Z",
  "pubdate": "2026-08-27T17:20:57.003Z",
  "executiveSummary": "AVideo versions prior to 24.0 contain a Server-Side Request Forgery (SSRF) vulnerability originating from the isSSRFSafeURL function.\nThe vulnerability occurs due to a failure in the validation logic to identify embedded IPv4 addresses within specific IPv6 transition mechanisms, specifically NAT64, 6to4, and Teredo formats.\nAn unauthenticated, remote attacker can leverage the LiveLinks proxy endpoint to bypass security filters intended to block access to internal network resources.\nBy crafting requests using these IPv6 transition formats, attackers can redirect the server to interact with arbitrary internal services or cloud metadata endpoints (e.g., 169.254.169.254).\nThe impact is significant, as it permits unauthorized access to sensitive internal network infrastructure that should be unreachable from the public internet. The primary risk involves sensitive data exfiltration, service enumeration, or unauthorized interaction with internal APIs, potentially leading to full compromise depending on the target environment's architecture.",
  "technicalDetails": "The vulnerability resides within the isSSRFSafeURL function, which is responsible for sanitizing and validating URLs processed by AVideo to prevent SSRF attacks. The flaw is rooted in an insufficient parsing mechanism that fails to normalize or inspect the embedded IPv4 addresses encapsulated within IPv6 transition address formats.\nSpecifically, the application's denylist or validation filter ignores IPv4 addresses when they are formatted using NAT64 (RFC 6146), 6to4 (RFC 3056), or Teredo (RFC 4380) tunnel architectures. Because these transition protocols effectively map IPv4 address space into the IPv6 address range, an attacker can represent private or loopback IPv4 addresses as valid-looking IPv6 addresses.\nThe attack vector involves targeting the LiveLinks proxy endpoint. When the application receives a request, the isSSRFSafeURL function checks the provided destination URL. Because the function does not properly decompose or validate the IPv4 component within the Teredo or 6to4 prefix, the check passes, incorrectly identifying the target as a safe or non-internal destination.\nAn attacker can exploit this by crafting a request to the LiveLinks endpoint, passing a malicious URL containing an IPv4 address encoded in one of these transition formats (e.g., using the 2002::/16 block for 6to4). Upon processing, the server-side logic decodes the address—or relies on the underlying system network stack to resolve the target—effectively bypassing the security filter.\nOnce the filter is bypassed, the AVideo server acts as an open proxy, initiating an outbound connection to the intended internal resource. This allows the attacker to query cloud instance metadata services—often hosting sensitive IAM credentials—or scan internal network services that do not require authentication or are trusted based on their network location. The vulnerability is exploitable by unauthenticated attackers, as the LiveLinks endpoint is reachable without prior access credentials, and it requires no elevated privileges within the AVideo environment. The lack of robust input normalization in the validation logic represents a critical failure in enforcing the security boundary between public-facing proxy functions and the internal network environment."
}