CVE-2026-39821: 
cAdvisor vulnerability analysis and mitigation

CVE-2026-39821 is an authorization bypass vulnerability in the Go golang.org/x/net/idna package, caused by improper validation of Punycode-encoded domain labels. The ToASCII and ToUnicode functions incorrectly accept Punycode-encoded labels that decode to ASCII-only values — for example, ToUnicode("xn--example-.com") returns "example.com" instead of returning an error. This flaw affects all versions of golang.org/x/net prior to 0.55.0. It was published on May 22, 2026, with a patch released on May 29, 2026. The vulnerability carries a CVSS v3.1 base score of 9.6 (Critical) (Go Vuln DB, ENISA EUVD).

The root cause is classified as CWE-1289 (Improper Validation of Unsafe Equivalence in Input). The idna package's ToASCII and ToUnicode functions fail to reject Punycode-encoded labels that, when decoded, resolve to a purely ASCII hostname — a condition that is invalid per IDNA standards and should produce an error. An attacker exploiting this flaw can supply a Punycode-encoded hostname (e.g., xn--example-.com) to a program that performs access control checks on the ASCII form before converting to Unicode. Because the ASCII check may block example.com but permit xn--example-.com, and the subsequent Unicode conversion yields example.com, the attacker bypasses the intended restriction. The attack requires only low privileges and no user interaction, and operates over the network with a changed scope (Go Vuln DB, golang-announce).

Successful exploitation allows a network-accessible attacker to bypass hostname-based access controls in any Go application that uses the idna package for domain validation. The attacker can gain unauthorized access to resources or services that are restricted by ASCII hostname checks, with high impact to both confidentiality and integrity. Availability is not directly impacted. Applications performing SSRF protections, tenant isolation, or allowlist/denylist enforcement based on hostname strings are particularly at risk of privilege escalation or unauthorized data access (Go Vuln DB, golang-announce).

As of the time of reporting, there is no public proof-of-concept exploit and no evidence of in-the-wild exploitation (Feedly). The EPSS score is approximately 0.045%, reflecting low current exploitation probability. The vulnerability is not listed in the CISA Known Exploited Vulnerabilities (KEV) catalog. Detection coverage exists via Nessus (plugin 317702) and Qualys (IDs 762973, 6035834) (Tenable).

1. Identify a vulnerable target: Find a Go application that uses golang.org/x/net/idna (versions < 0.55.0) and performs hostname-based access control checks — such as SSRF filters, allowlists, or tenant isolation logic — on the ASCII hostname before converting to Unicode.
2. Craft a Punycode-encoded hostname: Construct a Punycode label that decodes to the target ASCII hostname (e.g., use xn--example-.com to represent example.com). The encoding must be syntactically valid Punycode but decode to a purely ASCII value.
3. Submit the crafted hostname: Send a request to the target application using the Punycode-encoded hostname in the relevant field (e.g., URL, Host header, API parameter).
4. Bypass access control: The application's pre-conversion check evaluates the Punycode string (e.g., xn--example-.com), which may not match the blocked ASCII hostname (example.com), so the check passes.
5. Achieve unauthorized access: The application subsequently calls ToUnicode() or ToASCII(), which incorrectly returns example.com without error, granting the attacker access to the restricted resource as if they had supplied the legitimate hostname (Go Vuln DB, golang-announce).

• Network: Incoming requests containing Punycode-encoded hostnames (labels beginning with xn--) in Host headers, URL parameters, or API fields targeting services with hostname-based access controls.
• Logs: Application access logs showing requests with xn---prefixed domain labels that correspond to blocked ASCII hostnames; unexpected successful access to restricted endpoints from such requests.
• Application Behavior: Access control decisions that permit requests using Punycode-encoded hostnames to resources that should be restricted when the equivalent ASCII hostname is used directly.

Upgrade golang.org/x/net to version 0.55.0 or later, which correctly rejects Punycode-encoded labels that decode to ASCII-only values (Go Vuln DB). As a workaround where immediate upgrade is not possible, applications should perform hostname validation checks after Unicode conversion rather than before, or implement additional logic to explicitly reject Punycode-encoded hostnames that decode to ASCII-only values. Downstream distributions including SUSE, openSUSE, Red Hat, Ubuntu, and Chainguard/Wolfi have issued or are issuing updated packages (SUSE Advisory, Red Hat Errata).

The Go team announced the vulnerability via the golang-announce mailing list and published a detailed advisory in the Go vulnerability database (golang-announce, Go Vuln DB). A technical blog post on dev.to explored how this flaw could be used to bypass SSRF guards in Go applications (dev.to). Multiple Linux distributions including SUSE, openSUSE, Red Hat, and Ubuntu have issued security advisories and updated packages. AWS Inspector has also incorporated detection for this CVE.