GCVE-110-VULN-PYPI-2026-000631

If you run aimarket-mcp 0.1.0 through 0.6.1 and let callers you do not fully trust use the web_fetch tool (over the stdio server or the HTTP server's tools/call), including a model following a prompt injection, they can make the server fetch addresses inside your network, such as 169.254.169.254 or an internal web service, and read the page text it returns. security.validate_url refuses private, loopback, link-local and reserved addresses, but the request is then made by name, so httpx resolves the host a second time and a name that answers public for the check and private a moment later is fetched (DNS rebinding). In 0.1.0 through 0.3.0 this holds for every URL. From 0.4.0 security.pin_target pins plain HTTP to the checked address, but https:// URLs are still requested by name, and the client honours HTTPS_PROXY, ALL_PROXY and SSL_CERT_FILE, so behind a TLS-inspecting egress proxy, which resolves the name itself and re-signs with a CA the server trusts, an internal https page is returned too; without such a proxy the certificate check fails and the error still tells which internal addresses accept TLS connections. In every affected version the check also treats the NAT64 prefix 64:ff9b::/96 and 6to4 as public, so on a host that routes them an IPv6 literal carrying a private IPv4 address passes. Fixed in 0.6.2: every request goes to the checked address with the name in Host and TLS SNI, proxy and CA environment variables are ignored, and IPv4-mapped, 6to4 and NAT64 addresses are judged by the IPv4 address they carry. The same weakness in aimarket-signal-hunt is GCVE-110-PYPI-2026-021946. Affects 0.1.0 through 0.6.1.