CVE-2024-12224

What it actually does

The idna library accepts Punycode labels that produce no non-ASCII output, causing distinct ASCII or root labels such as example.org and xn--example-.org to compare as equal after processing.

Why it matters to the business

Applications that rely on hostname comparison for access decisions may grant unauthorized privileges, increasing risk of security bypass in environments using the vulnerable library.

How an attack unfolds

An attacker registers a DNS name and obtains a TLS certificate for an xn--masked label that the library maps to a target domain, then supplies the name in a context where the application performs a privilege check based on the incorrectly equal comparison.

How to fix it

Upgrade the idna package to version 0.6.0 or newer. On SUSE Linux Enterprise Live Patching 12 SP5 systems apply kgraft-patch-SLE12-SP5_Update_51 version 7-2.1 or later.

How to confirm the fix worked

Confirm the installed idna version is newer than 0.5.0, then test that example.org and xn--example-.org are no longer treated as equal and that example.org.xn-- and example.org. remain distinct.

Typical attack path

1. Locate an application that uses idna for hostname comparison in a privilege decision
2. Craft a Punycode label that the library maps to the target domain
3. Register the malicious domain and obtain a matching TLS certificate
4. Cause the application to perform the flawed comparison during an access check
5. Obtain elevated access or bypass intended restrictions

How to detect it

Inspect application logs for hostname comparisons involving xn-- prefixes that unexpectedly match target domains, and review DNS or certificate logs for registrations of such labels.

What your security team should do

• Update idna to a fixed version across all affected systems immediately
• Audit code paths that compare hostnames for authorization decisions
• Review dependency manifests for any remaining pinned versions 0.5.0 or earlier