CVE-2026-45409

What it actually does

This is a denial-of-service flaw in the Python IDNA library's handling of oversized internationalized domain name inputs. Before version 3.15, certain crafted Unicode inputs can reach expensive context-validation logic, including valid_contexto, before the input is rejected for exceeding domain length limits. Payloads made of repeated Arabic-Indic digit characters such as \u0660, or repeated middle-dot characters such as \u30fb followed by a CJK character such as \u6f22, can cause disproportionately high CPU consumption when passed to idna.encode(), per-label conversion functions, or codec paths. The vulnerability does not provide code execution, data disclosure, or privilege escalation; its impact is availability degradation in applications that pass attacker-controlled domain-like strings into the IDNA library without enforcing length limits first.

Why it matters to the business

Applications, APIs, web services, crawlers, validators, authentication flows, URL processing pipelines, mail-processing systems, and security tools that normalize user-supplied hostnames with the affected IDNA package may become slow or unavailable when processing maliciously large inputs. Because exploitation requires only network access to a feature that accepts domain names, URLs, email addresses, redirects, callback hosts, or similar inputs, exposed services can experience increased latency, worker exhaustion, request backlogs, elevated compute costs, or partial outages. The CVSS score is moderate and EPSS is currently low, and it is not listed in CISA KEV, but the package is commonly used transitively in Python ecosystems, so indirect exposure through dependencies should be considered.

How an attack unfolds

An attacker first identifies an application feature that accepts a domain name, URL, email address, webhook target, redirect target, federation identifier, certificate name, or other hostname-like value. They then submit an abnormally long Unicode string designed to trigger expensive IDNA context validation before length rejection, for example a long sequence of Arabic-Indic digit characters or middle-dot characters followed by a CJK character. If the application passes this input directly to idna.encode() or related IDNA conversion paths without first enforcing the 253-character DNS name limit, the Python process spends excessive CPU time evaluating the invalid input. Repeated requests can tie up application workers, increase response times, trigger timeouts, and reduce service availability. There is no indication from the provided intelligence that this vulnerability is currently used by named threat actors or ransomware campaigns.

How to fix it

Upgrade the Python IDNA package to version 3.15 or later wherever it is installed directly or transitively. Version 3.15 extends early length rejection across idna.encode(), per-label conversions, and codec support. If immediate upgrade is not possible, enforce strict input validation before calling IDNA functions: reject any full domain name longer than 253 characters, reject labels longer than 63 characters, cap total request body and parameter sizes, and apply request-rate limiting to endpoints that process domain-like input. Review dependency lockfiles, container images, vendored packages, and application bundles for embedded or pinned versions earlier than 3.15. Version 3.14 reduced exposure for common encode paths, but version 3.15 should be treated as the complete fix based on the supplied advisory.

How to confirm the fix worked

Confirm that the runtime imports IDNA version 3.15 or later, for example by checking package metadata with pip show idna, pip freeze, pipdeptree, poetry show, pipenv graph, container software bills of materials, or application dependency lockfiles. Validate application behavior by submitting oversized domain-like inputs in a controlled test environment and confirming they are rejected quickly before IDNA conversion. Tests should include full domain names greater than 253 characters and labels greater than 63 characters, including repeated Unicode characters such as Arabic-Indic digit zero and middle-dot sequences. Monitor CPU time and request latency during validation; patched or mitigated systems should fail fast with a validation error rather than consuming significant CPU. Also verify that alternate code paths using per-label conversion or codec support are covered, not only direct idna.encode() calls.

Typical attack path

1. Find an internet-facing or remotely reachable feature that accepts user-controlled hostnames, URLs, email addresses, callback destinations, or domain-like identifiers.
2. Craft an oversized Unicode input that greatly exceeds normal domain-name length limits and contains repeated contextual IDNA characters such as \u0660 or \u30fb sequences.
3. Submit the payload to the vulnerable endpoint so the application passes it to the Python IDNA library without preliminary length validation.
4. Cause the affected library to perform expensive context validation before rejecting the invalid input.
5. Repeat or parallelize requests to consume CPU, exhaust workers, increase latency, and degrade service availability.

How to detect it

Look for evidence of availability-focused abuse rather than compromise artifacts, since this flaw does not create files, spawn malware, or provide code execution by itself. Useful sources include web access logs, API gateway logs, WAF logs, reverse proxy logs, application logs, APM traces, Python exception logs, load balancer metrics, container CPU metrics, and process-level telemetry. Focus on requests with unusually long parameters or bodies containing domain, URL, email, hostname, redirect, callback, webhook, issuer, audience, or federation fields, especially if they contain repeated Unicode contextual characters and correlate with high CPU, long request duration, worker timeouts, HTTP 408/429/499/500/502/503/504 responses, or application server timeout messages. In Python telemetry, investigate long-running requests whose stack traces or profiling samples include idna.encode, idna.core.valid_contexto, idna.core.check_label, idna.core.alabel, idna.core.ulabel, or codec-based IDNA conversions. Because exploit payloads may be percent-encoded, JSON-escaped, form-encoded, or UTF-8 encoded, normalize logs before searching where possible.

• \\u0660
• %D9%A0
• ٠٠٠٠٠٠٠٠
• \\u30fb
• %E3%83%BB
• ・・・・・・・・
• \\u6f22
• %E6%BC%A2
• idna.encode
• idna.core.valid_contexto
• idna.core.check_label
• idna.core.alabel
• idna.core.ulabel
• UnicodeError: label empty or too long
• UnicodeError: Domain too long
• gunicorn timeout
• WORKER TIMEOUT
• upstream timed out
• request timed out

What your security team should do

• Inventory Python applications and services that include the idna package directly or through dependencies, prioritizing internet-facing services and systems that process URLs, domains, emails, webhooks, redirects, or third-party identifiers.
• Upgrade idna to version 3.15 or later across application dependencies, containers, serverless packages, CI build artifacts, and vendored libraries.
• Add application-layer validation that rejects domain names over 253 characters and labels over 63 characters before calling any IDNA conversion function.
• Apply rate limits, request size limits, and timeout controls to endpoints that accept domain-like input, especially unauthenticated endpoints.
• Search logs for historical requests containing very long Unicode hostname, URL, email, redirect, or callback parameters associated with timeouts, 5xx responses, elevated latency, or CPU spikes.
• Add regression tests for oversized IDNA inputs so future dependency or application changes do not reintroduce expensive pre-validation behavior.
• Because EPSS is low and the flaw is not in CISA KEV, prioritize remediation based on exposure: patch internet-facing and unauthenticated input paths first, then internal and authenticated services.