CVE-2026-45409
Summary
by MITRE • 06/06/2026
Internationalized Domain Names in Applications (IDNA) for Python provides support for Internationalized Domain Names in Applications (IDNA) and Unicode IDNA Compatibility Processing. In versions prior to 3.15, payloads such as `"\u0660" * N` or `"\u30fb" * N + "\u6f22"` utilize the `valid_contexto` function prior to length rejection, and for high values of `N` will take a long time to process. This is the same issue as CVE-2024-3651, however the original remediation in 2024 was not a complete fix. A specially crafted argument to the `idna.encode()` function could consume significant resources. This may lead to a denial-of-service. Starting in version 3.14, the function rejects long inputs as soon as practicable prior to any further processing to minimize resource consumption. In version 3.15, this approach was extended to lesser used alternate functions (i.e. per-label conversions and codec support). A workaround is available. Domain names cannot exceed 253 characters in length. If this length limit is enforced prior to passing the domain to the `idna.encode()` function, it should no longer consume significant resources. This is triggered by arbitrarily large inputs that would not occur in normal usage, but may be passed to the library assuming there is no preliminary input validation by the higher-level application.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 06/06/2026
The Internationalized Domain Names in Applications (IDNA) library for Python serves as a critical component in handling Unicode domain names within applications, enabling support for international character sets beyond the traditional ASCII domain name format. This library implements Unicode IDNA Compatibility Processing to ensure proper encoding and decoding of domain names that contain non-ASCII characters, making it essential for global internet applications that need to support multilingual domain names. The vulnerability affects versions prior to 3.15 where specific Unicode character sequences can trigger excessive computational overhead during processing, creating potential security risks for applications that rely on this library for domain name handling.
The technical flaw manifests in the `valid_contexto` function which processes certain Unicode character combinations such as `"\u0660" N` or `"\u30fb" N + "\u6f22"` where N represents large values that cause the function to perform extensive computations before any length validation occurs. This processing pattern exploits the underlying algorithm's handling of context-sensitive validation rules for Unicode characters, particularly those that require complex compatibility processing. The vulnerability operates at the intersection of Unicode normalization and IDNA compliance checking, where the library's validation logic becomes computationally expensive when processing sequences that involve zero-width characters and compatibility mappings. This behavior creates a resource exhaustion scenario where processing time increases exponentially with input size, making it susceptible to denial-of-service attacks.
The operational impact of this vulnerability extends beyond simple performance degradation to potentially enabling full denial-of-service conditions in applications that process untrusted domain name inputs. Attackers can craft malicious domain name inputs that trigger the computationally expensive validation paths, consuming significant CPU resources and potentially causing application crashes or unresponsiveness. This vulnerability particularly affects web applications, email servers, and any system that processes domain names from external sources without proper input validation. The issue is especially concerning because it can be triggered by inputs that appear legitimate but contain Unicode sequences designed to exploit the library's processing behavior, making detection and prevention challenging.
The remediation implemented in version 3.14 introduced early input validation by rejecting long inputs before any processing begins, which significantly reduced the attack surface by preventing the computationally expensive validation paths from being executed. This approach aligns with security best practices for preventing resource exhaustion attacks and follows the principle of defense in depth as outlined in the CWE-400 category for excessive resource consumption. The fix in version 3.15 extended this protection to additional functions including per-label conversions and codec support, demonstrating a comprehensive approach to addressing the vulnerability across all library entry points. Organizations should note that this vulnerability follows the ATT&CK technique T1499.004 for resource exhaustion attacks, where adversaries exploit application vulnerabilities to consume system resources. The recommended mitigation strategy involves enforcing the standard domain name length limit of 253 characters before passing inputs to the `idna.encode()` function, which serves as an effective workaround that prevents the vulnerable code paths from being executed. This approach ensures that even if malformed inputs reach the library, they will be rejected before any expensive processing occurs, providing a robust defense against this specific class of denial-of-service attacks.