[herdiyana256]

load_web_page validates fetch targets through _is_blocked_address, which rejects any address that is not global. That correctly blocks IPv4 private, loopback, and link-local literals, hostnames that resolve to them, and the IPv4-mapped IPv6 form ::ffff:a.b.c.d.

It does not block two other IPv6 encodings that carry an internal IPv4 address. The NAT64 well-known prefix 64:ff9b::/96 (RFC 6052) and the deprecated IPv4-compatible form ::a.b.c.d both embed an IPv4 address in their low 32 bits, but the standard library classifies them as globally routable, so is_global is True and the guard allows them. As a result 64:ff9b::169.254.169.254 and ::169.254.169.254 pass the check, and the same holds for private and loopback ranges.

On a NAT64-enabled network (common in IPv6-only environments) a connection to 64:ff9b::169.254.169.254 is translated by the NAT64 gateway to the IPv4 link-local metadata endpoint 169.254.169.254, so an attacker who can influence the URL passed to the tool can reach cloud metadata or other internal services despite the guard. The target can also be delivered through DNS by publishing an AAAA record inside the prefix.

This change unwraps the embedded IPv4 address from the IPv4-mapped, NAT64 well-known, and IPv4-compatible forms and re-checks it, so a target is blocked when either the IPv6 address or its embedded IPv4 address is non-global. NAT64 to a genuinely public IPv4 such as 64:ff9b::8.8.8.8 is still allowed, and the existing load_web_page test suite continues to pass.

[rohityan]

Hi @herdiyana256 , Thank you for your contribution! We appreciate you taking the time to submit this pull request.
Can you also add a unit test and fix the failing CI checks.

[herdiyana256]

Thanks @rohityan! Added unit tests in tests/unittests/tools/test_load_web_page.py:

• test_is_blocked_address_blocks_embedded_internal_ipv4 / test_is_blocked_address_allows_embedded_public_ipv4 — parametrized over the NAT64 well-known prefix (64:ff9b::/96), the deprecated IPv4-compatible form (::a.b.c.d) and the IPv4-mapped form: blocked when the embedded IPv4 is internal (loopback / 169.254.169.254 / private), allowed when it is public.
• End-to-end load_web_page cases for a NAT64-wrapped metadata literal, an IPv4-compatible loopback literal, and a hostname resolving (via getaddrinfo) to a NAT64-wrapped 169.254.169.254 — all confirm the request is refused before any socket send.

All pass locally (pytest tests/unittests/tools/test_load_web_page.py), CLA/checks green. PTAL.

[herdiyana256]

Merged main in to clear the out-of-date branch state; it merged cleanly with no conflicts. pytest tests/unittests/tools/test_load_web_page.py is green (21 passed) on the updated tree, including the NAT64 / IPv4-compatible / IPv4-mapped coverage added earlier.

@xuanyang15 this one is assigned to you and the review comments from @rohityan (unit tests + CI) are already addressed. Would you mind taking a look when you have a moment?

[xuanyang15]

@herdiyana256 Thanks for creating this PR! This change appears to be a duplicate of earlier PR #6347, which addresses the same NAT64 and IPv4-compatible SSRF vulnerability in load_web_page and was submitted on 2026-07-08 (18 days prior to PR #6486).

We will proceed with #6347 to credit the earlier PR.