MCP Fetch egress policy missed IPv4 addresses embedded in NAT64

An IPv6 string can be a translation wrapper around a restricted IPv4 destination. The Fetch validation did not inspect the embedded destination in the documented prefix, so it could authorize a URL whose translated socket would reach a forbidden service. primary evidence documents the logic gap separately from the IDNA mismatch case.

The supplied reproduction was a classifier test. It does not demonstrate successful cloud-metadata theft on a network lacking DNS64/NAT64 translation.

Egress checks need to classify translated endpoints and enforce the final socket destination. Fixing generic private IPv4 parsing without NAT64 cases is incomplete.

This is a different mechanism from the IDNA case: the URL can contain one syntactically valid IPv6 address that embeds a private or link-local IPv4 destination in 64:ff9b::/96. The server classified the wrapper as public without examining its low 32 bits, while actual reachability requires a NAT64/DNS64 egress translator. The advisory includes a classifier bypass, not an independently observed request to a real metadata service. Version 2026.10.24 adds the missing network classification; operators still need to enforce actual outgoing socket policy.