CVE-2026-39821

What it actually does

This is an input-validation flaw in Go's IDNA hostname conversion logic. The affected ToASCII and ToUnicode behavior can incorrectly accept malformed Punycode/ACE labels beginning with xn-- that decode to an ASCII-only hostname label instead of rejecting them. Applications that make authorization, routing, tenancy, allowlist, denylist, or privilege decisions on one hostname representation and then later convert it to another representation can be tricked into treating a blocked or privileged ASCII hostname as if it were an allowed internationalized hostname. The result is hostname confusion that can enable authorization bypass and privilege escalation in software using the affected IDNA functionality.

Why it matters to the business

Applications that rely on Go IDNA hostname processing for access control, domain ownership checks, allowlists, denylists, proxy routing, SSO callback validation, multi-tenant isolation, or administrative boundary checks may grant access to resources that should have been blocked. The CVSS score is high because exploitation can be remote, low-complexity, and may allow compromise of confidentiality and integrity when hostname-based privilege checks are security-sensitive. EPSS is currently low and there is no known CISA KEV listing or ransomware association, but the pattern is easy to misuse in many applications because hostname normalization is commonly embedded in authentication, authorization, and network-routing logic.

How an attack unfolds

An attacker identifies an application feature that accepts a user-controlled hostname, domain, callback URL, tenant domain, upstream target, or service name and uses Go's IDNA conversion routines. The application first checks the ASCII form of the supplied hostname against a policy, such as denying example.com or reserving it for privileged users. The attacker supplies a crafted ACE/Punycode form such as a label beginning with xn-- that should be rejected but is incorrectly accepted by the vulnerable conversion logic. Because the pre-conversion value does not exactly match the protected hostname, the policy check may pass. The application then converts the value with ToUnicode or otherwise normalizes it, causing the malformed label to collapse into the protected ASCII hostname. Subsequent authorization, routing, certificate, callback, or resource-access logic operates on the privileged hostname, allowing the attacker to reach functionality or data associated with a name they were not authorized to use.

How to fix it

Upgrade to a Go/toolchain or golang.org/x/net/idna version that contains the vendor fix as soon as one is available for the affected product line; no exact fixed version was provided in the input, so teams should monitor the Go security advisory and package release notes and pin to the first non-vulnerable release. In the meantime, do not make security decisions on a different hostname representation than the one used later for routing or access. Canonicalize and validate hostnames once, reject invalid ACE/Punycode labels, and perform authorization on the exact canonical value that will be used downstream. Add explicit validation that labels beginning with xn-- must decode to valid non-ASCII IDNA labels and must not decode to ASCII-only labels. Avoid denylist-only hostname controls where possible; use strict allowlists, verified ownership, and exact canonical-domain comparisons. For high-risk services, add compensating controls at the application or gateway layer to reject suspicious malformed Punycode hostnames until dependencies are patched.

How to confirm the fix worked

Confirm all applications and libraries using Go IDNA handling are built with a fixed Go/x/net dependency once a fixed version is released. Run dependency inventory checks for golang.org/x/net/idna and any vendored copies. Add regression tests verifying that malformed labels such as ToUnicode("xn--example-.com") fail validation rather than returning "example.com". Test security-sensitive hostname workflows with crafted xn-- inputs and confirm policy checks, routing, and authorization all use the same canonical hostname representation. Review CI/CD dependency lockfiles and compiled artifacts to ensure rebuilt services no longer include vulnerable IDNA code. Where a compensating control is deployed, verify requests containing malformed ACE labels are rejected before business logic performs authorization or routing.

Typical attack path

1. Find an application endpoint or workflow that accepts a hostname, domain name, URL, callback domain, tenant domain, or upstream target controlled by a low-privileged user.
2. Determine whether access controls compare the raw ASCII hostname before later applying IDNA/Punycode normalization.
3. Craft a malformed ACE/Punycode label beginning with xn-- that decodes to an ASCII-only label that should have been rejected.
4. Submit the crafted hostname in the vulnerable workflow.
5. Bypass the initial allowlist, denylist, ownership, or privilege check because the raw submitted hostname does not match the protected ASCII name.
6. Trigger subsequent conversion through the affected IDNA ToUnicode or ToASCII behavior.
7. Cause the application to treat the input as the protected ASCII hostname and gain unauthorized access, routing, or privilege.

How to detect it

This vulnerability does not create a universal host-level artifact; evidence of exploitation is most likely in application, API gateway, reverse proxy, authentication, authorization, domain-management, tenant-onboarding, callback-validation, and audit logs. Search for user-supplied hostnames, domains, URLs, redirect_uri values, callback URLs, upstream targets, or tenant domains containing ACE/Punycode labels beginning with xn--, especially labels that include unusual trailing hyphens or later normalize to an ASCII-only protected name. Compare raw submitted hostname fields with normalized/canonical hostname fields where both are logged; exploitation is indicated by a raw xn-- value being accepted and then processed as a sensitive ASCII hostname. Review authorization logs for allow/deny mismatches, such as a protected domain normally denied in raw form but allowed when supplied as Punycode. Investigate successful privileged actions, tenant changes, routing decisions, SSO/OAuth callback registrations, webhooks, or proxy fetches shortly after suspicious xn-- submissions. Because there are no known named threat actors, KEV listing, or public exploit maturity in the supplied data, detection should focus on behavior and normalization mismatches rather than actor-specific indicators.

• xn--
• xn--example-.com
• ToUnicode("xn--example-.com")
• raw_host=xn--
• hostname=xn--
• domain=xn--
• redirect_uri=*xn--*
• callback_url=*xn--*
• url=*xn--*
• Host: xn--

What your security team should do

• Inventory services written in Go or using Go-based components that accept or process hostnames, domains, URLs, callback URLs, tenant domains, federated identity endpoints, proxy targets, or service discovery names.
• Prioritize review of systems where hostname decisions affect authorization, tenant isolation, administrative access, SSRF protection, allowlists, denylist enforcement, certificate validation, or request routing.
• Monitor Go and golang.org/x/net security advisories for the fixed release and schedule upgrades promptly despite the currently low EPSS score, because exploitation depends heavily on application logic and may not require public exploit code.
• Add application-layer validation to reject malformed ACE/Punycode labels beginning with xn-- that decode to ASCII-only labels until the underlying dependency is patched.
• Ensure authorization checks are performed after canonicalization and against the same canonical hostname used for downstream access.
• Create regression tests for IDNA normalization edge cases and require them for services that perform hostname-based security decisions.
• Search historical logs for suspicious xn-- hostnames in authentication, authorization, routing, callback, domain-registration, proxy, and API request logs.
• If suspicious requests are found, investigate whether the normalized hostname maps to a protected, denied, administrative, internal, or tenant-owned domain.