CVE-2026-126348: Addressable display_uri can show misleading hosts with invalid Punycode A-labels
Impact
Addressable::IDNA.tounicode, in the pure-Ruby IDNA implementation, decodes Punycode labels (labels beginning with xn--) that are not valid A-labels. Those labels are returned in decoded form, when they should be returned unchanged. That includes:
- labels that decode to only ASCII characters, e.g. xn--google- decodes to google; - labels that decode to text that doesn't convert back to the same label (RFC 3490 §4.2), e.g. text that isn't in normalized form.
Addressable::URI#displayuri uses tounicode, so for https://xn--google-.example.org/ it displays the host google.example.org, while #host, #normalizedhost and any connection made from the URI use xn--google-.example.org. An attacker who controls a domain can therefore have a URI displayed as a host they don't control. Applications that compare the result of tounicode against a list of trusted names can likewise treat two different hosts as the same.
The native IDNA implementation, used when libidn and the idn-ruby gem are installed, is not affected. toascii and normalizedhost are not affected.
Affected Versions
This vulnerability affects Addressable >= 2.0.0, the first version with the pure-Ruby IDNA implementation, when that implementation is in use. It is fixed in 2.9.1, where such labels are returned unchanged, as with libidn.
Workarounds
- Install libidn and the idn-ruby gem, so that Addressable uses the native IDNA implementation. - Don't make security decisions on displayuri or tounicode output. Compare hosts using normalizedhost.
Credits
Reported by @tonghuaroot.
For more information
If there are any questions or comments about this advisory: Open an issue
Other sources
Addressable is an alternative implementation to the URI implementation that is part of Ruby's standard library. From 2.0.0 until 2.9.1, the pure-Ruby Addressable::IDNA.tounicode implementation decodes invalid Punycode A-labels instead of returning them unchanged. Labels that decode to ASCII text or fail to convert back to the same A-label can therefore make Addressable::URI#displayuri show a trusted-looking host while host, normalizedhost, and the connection target retain the attacker-controlled encoded host. A trusted-name comparison using Addressable::IDNA.tounicode output can also treat two different hosts as the same without displaying the URI. The native libidn implementation, toascii, and normalizedhost are unaffected. This issue is fixed in version 2.9.1.
— MITRE
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
rubygems/addressableto a version that resolves this vulnerability.Fixed in 2.9.1 - Upgrade
Upgrade
Addressableto a version that resolves this vulnerability.Fixed in 2.9.1 - Compensating control
Do not make security decisions based on Addressable display_uri or to_unicode output; compare hosts using normalized_host instead.
- Compensating control
Install libidn and the idn-ruby gem so Addressable uses the native IDNA implementation.
Event History
Frequently Asked Questions
Which deployments are exposed to this issue?
Deployments using Addressable's pure-Ruby IDNA implementation are affected. The native IDNA implementation is not affected when both libidn and the idn-ruby gem are installed.
What does an attacker need to exploit this?
An attacker needs control of a domain containing an invalid Punycode A-label and must cause a user or application to use a URI containing that host. Exploitation is relevant where the application displays display_uri or compares to_unicode output to trusted host names.
What can be used safely if an immediate update is not possible?
Do not make trust decisions based on Addressable::IDNA.to_unicode or Addressable::URI#display_uri. Use to_ascii or normalized_host for host handling, as they are not affected.
How can I identify potentially affected behavior?
Check whether the application uses the pure-Ruby IDNA implementation and uses to_unicode or display_uri for display or hostname allowlisting. Affected behavior can be observed when a URI such as https://xn--google-.example.org/ displays google.example.org while its host and normalized_host remain xn--google-.example.org.