Skip to content

Conversation

@gmsftdev
Copy link

idna accepts Punycode labels that do not produce any non-ASCII when decoded

Problem

idna 0.5.0 and earlier accepts Punycode labels that do not produce any non-ASCII output, which means that either ASCII labels or the empty root label can be masked such that they appear unequal without IDNA processing or when processed with a different implementation and equal when processed with idna 0.5.0 or earlier.

Concretely, example.org and xn--example-.org become equal after processing by idna 0.5.0 or earlier. Also, example.org.xn-- and example.org. become equal after processing by idna 0.5.0 or earlier.

In applications using idna (but not in idna itself) this may be able to lead to privilege escalation when host name comparison is part of a privilege check and the behavior is combined with a client that resolves domains with such labels instead of treating them as errors that preclude DNS resolution / URL fetching and with the attacker managing to introduce a DNS entry (and TLS certificate) for an xn---masked name that turns into the name of the target when processed by idna 0.5.0 or earlier.

Remedy

Updated url 2.2 to url 2.5.4 which updates the idna dependency idna 0.5 to idna 1.0.3.

@gmsftdev gmsftdev self-assigned this Jul 21, 2025
@gmsftdev gmsftdev requested a review from DrChat July 21, 2025 21:13
@gmsftdev gmsftdev changed the title Update url dependency from 2.2.0 to 2.5.4 Bump url from 2.2.0 to 2.5.4 Jul 21, 2025
@gmsftdev gmsftdev marked this pull request as ready for review July 21, 2025 21:21
@gmsftdev gmsftdev merged commit fee03cc into main Jul 21, 2025
4 checks passed
@gmsftdev gmsftdev deleted the user/gmsftdev/idnaupdate branch July 21, 2025 22:07
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants