CVE-2026-85738 in TREK
Summary
by MITRE • 09/24/2026
TREK is a collaborative travel planner. Prior to 3.4.0, the checkSsrf logic in server/src/utils/ssrfGuard.ts does not recognize NAT64, 6to4, or Teredo IPv6 transition addresses that encode an IPv4 destination. An authenticated user who controls a DNS record can supply a URL whose AAAA result is a transition address embedding a private, loopback, or link-local IPv4 target, and isAlwaysBlocked and isPrivateNetwork classify the address as allowed. In a deployment that routes the applicable transition format, user-facing imports, webhooks, integrations, or plugin egress can reach internal services or cloud metadata and expose returned information. This issue is fixed in version 3.4.0.
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.
Analysis
by VulDB Data Team • 09/24/2026
The vulnerability identified in TREK versions prior to 3.4.0 represents a critical Server-Side Request Forgery (SSRF) flaw rooted in the application's network validation logic, specifically within the ssrfGuard utility module. SSRF vulnerabilities generally fall under CWE-918 and are frequently associated with ATT&CK technique T1105, as they allow an attacker to manipulate server-side input processing to initiate requests to unintended internal or external resources. In this specific instance, the security control mechanism failed to adequately parse and validate IPv6 addresses that utilize transition mechanisms such as NAT64, 6to4, and Teredo. These protocols are designed to facilitate communication between IPv6-only networks and IPv4 infrastructure by encoding IPv4 addresses within IPv6 address formats. The flaw arises because the validation function did not recognize these encoded structures, leading it to incorrectly classify them as safe or public network destinations rather than recognizing the embedded private IPv4 targets they represent.
The operational impact of this vulnerability is significant for any deployment that supports routing through these specific transition mechanisms. An authenticated user who possesses control over a DNS record can exploit this logic error by supplying a URL where the AAAA DNS query resolves to an IPv6 address containing an encoded private, loopback, or link-local IPv4 destination. Because the application's internal checks incorrectly deemed such addresses as allowed, the server proceeds to make outbound requests on behalf of the user. This allows the attacker to bypass network segmentation and access sensitive internal services, cloud metadata endpoints, or other resources that are not intended to be reachable from the public internet. The exposure of returned information can lead to data leakage, unauthorized access to backend systems, and potentially further compromise of the infrastructure depending on the sensitivity of the accessed services.
To mitigate this vulnerability, organizations must upgrade TREK to version 3.4.0 or later, where the ssrfGuard logic has been updated to correctly identify and block IPv6 transition addresses that embed private IP ranges. In environments where upgrading is not immediately feasible, network-level controls should be implemented to restrict egress traffic from application servers, ensuring that requests cannot reach internal subnets or cloud metadata endpoints regardless of how they are addressed at the application layer. Additionally, input validation strategies should be enhanced to perform deep inspection of DNS responses and IP address formats, specifically checking for encoded IPv4 addresses within IPv6 structures before allowing server-side request initiation. This ensures compliance with secure coding practices that mandate rigorous validation of all network-related inputs to prevent SSRF attacks.