TREK EUVD-2026-86342

Requires an authenticated TREK account (PR:L) whose user can control a DNS record so its AAAA response resolves to a NAT64, 6to4, or Teredo IPv6 transition address encoding a private, loopback, or link-local IPv4 destination. The controlled hostname must be fed into a feature that performs server-side egress - user-facing imports, webhooks, integrations, or plugin egress. The decisive limiting factor is that the hosting environment must actually ROUTE the chosen transition format (NAT64/6to4/Teredo); deployments that do not route any of these formats are not exploitable via this path, which is why CVSS assigns AC:H. Impact is limited to confidentiality (disclosure of returned internal/metadata content); no integrity or availability effect. Fixed in TREK 3.4.0.

This is a genuine but conditional SSRF, not a top-tier priority. The CVSS 3.1 vector (AV:N/AC:H/PR:L/UI:N/S:C/C:H/I:N/A:N = 6.3, MEDIUM) is internally consistent with the description: network-reachable, but AC:H reflects two real hurdles - the attacker must control a DNS record AND the target deployment must actually route the specific IPv6 transition format (NAT64, 6to4, or Teredo) being abused. PR:L confirms authentication is required. There is NO EPSS score, NO CISA KEV listing, and NO public proof-of-concept, so exploitation status is 'no public exploit identified at time of analysis.' The scope change (S:C) and C:H are justified because a successful bypass reaches internal services or cloud metadata outside the application's security authority, exposing returned data (confidentiality only; I:N/A:N). No signals conflict: the moderate CVSS, absent exploitation telemetry, and niche product footprint all point to a low real-world urgency issue that should be patched routinely rather than as an emergency. The main caveat is that risk is highly deployment-dependent - an environment that does not route any of the named transition formats is effectively not exploitable via this path.

An authenticated TREK user who can control a DNS record points a hostname's AAAA record at an IPv6 NAT64/6to4/Teredo transition address that embeds an internal IPv4 target (e.g., 127.0.0.1 or a cloud metadata endpoint at 169.254.169.254). They then submit that hostname to a user-facing import, webhook, integration, or plugin egress feature; ssrfGuard.ts fails to decode the embedded IPv4 and permits the request, returning internal service or metadata content to the attacker. No public PoC exists, and exploitation only succeeds where the deployment actually routes the chosen transition format.