TL;DR. golang.org/x/net/idna.Lookup.ToASCII runs UTS-46 NFKC mapping on hostnames, which folds 100 non-ASCII Unicode digit codepoints (math superscripts, circled digits, fullwidth digits, math-styled digits, and others) to ASCII 0-9 . A pre-IDNA net.ParseIP check rejects the non-ASCII input as not-an-IP, hands it to the library, and gets back a real IPv4 literal. That literal then walks past SSRF allowlists, NO_PROXY lists, TLS-SNI routers, and cookie-domain validators that only checked the pre-IDNA value. The fix is a post-IDNA TrimRight + ParseAddr recheck. The blog has the bug, a runnable proof of concept against golang.org/x/net/http/httpproxy , the canonical safe pattern, and two just-shipped registry rules (CodeQL + Semgrep) that catch it in CI. I ran into this one while writing a Go HTTP client for a private project. I had a host allowlist, I had idna.Lookup.ToASCII canonicalising the host before dial, and I still could not convince myself the allowlist held. It did not.…