Description

WWBN AVideo contains a server-side request forgery filter bypass vulnerability in the isSSRFSafeURL function that fails to normalize NAT64 addresses written in hexadecimal form. Attackers can bypass SSRF protections by supplying hex-encoded NAT64 addresses like 64:ff9b::a9fe:a9fe to reach cloud metadata services and loopback interfaces.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "7.1",
  "pubDate": "2026-08-30T15:16:45.300Z",
  "pubdate": "2026-08-30T15:16:45.300Z",
  "executiveSummary": "WWBN AVideo is susceptible to a Server-Side Request Forgery (SSRF) vulnerability due to an insufficient input validation mechanism within the isSSRFSafeURL function.\nThe vulnerability stems from the application's failure to correctly normalize and sanitize NAT64-encoded IPv6 addresses provided in hexadecimal format.\nBy leveraging this flaw, an unauthenticated attacker can bypass existing security filters intended to block access to sensitive internal network resources, such as cloud instance metadata services (e.g., 169.254.169.254) and local loopback interfaces.\nSuccessful exploitation allows attackers to perform unauthorized requests from the server's context, potentially leading to information disclosure, unauthorized configuration changes, or pivot points into internal network segments.\nThe impact is significant, as it effectively renders server-side access control lists (ACLs) ineffective against crafted IPv6 payloads that the application logic fails to recognize as restricted internal addresses.\nRemediation requires the implementation of robust address normalization routines before validation and the application of strict allow-lists for outbound requests.",
  "technicalDetails": "The vulnerability resides within the isSSRFSafeURL function, which is designed to validate URLs before the application performs outbound HTTP requests. The root cause is a failure in the address resolution logic, specifically regarding the handling of IPv6 addresses that utilize the NAT64 prefix (64:ff9b::/96).\nIn standard network configurations, NAT64 is used to facilitate communication between IPv6-only networks and IPv4-only services by embedding an IPv4 address into an IPv6 format. The isSSRFSafeURL function performs basic string-based filtering to detect blacklisted internal IP ranges; however, it fails to normalize these addresses to a canonical representation before performing comparison checks.\nAn attacker can bypass the filter by supplying a target internal IPv4 address (e.g., 169.254.169.254) encoded into the NAT64 hexadecimal format (64:ff9b::a9fe:a9fe). Because the application logic does not expand or fully resolve this IPv6 address into its underlying IPv4 equivalent before the security check, the input bypasses the filter's blacklist logic. The underlying network stack subsequently expands the NAT64 address, allowing the request to be routed to the restricted internal endpoint.\nThe attack flow proceeds as follows: 1) The attacker identifies an input vector in AVideo that consumes a URL for external processing. 2) The attacker constructs a malicious payload utilizing the 64:ff9b::/96 prefix followed by the hex-encoded representation of a target internal IP address. 3) The application's isSSRFSafeURL function evaluates the payload; due to the lack of normalization, the check returns 'safe' as the hexadecimal string does not match the blocklist of IPv4 or standard IPv6 internal ranges. 4) The server initiates an outbound request to the target destination. 5) The network infrastructure or the application’s underlying HTTP client expands the address, successfully delivering the request to the restricted metadata service or internal resource. 6) The sensitive data or response is returned to the attacker through the AVideo interface or observable behavior, confirming unauthorized access to internal resources."
}