CVE-2026-17084 in Python
Summary
by MITRE • 08/18/2026
The "stringprep" module didn't process characters from RFC 3454 tables B.2 or B.3 correctly: the latest Unicode codepoint attributes were used instead of the specified Unicode 3.2.0. This behavior would cause mismatches when processing domain names using IDNA 2003 (the "idna" codec) and the in_table_b2() function of the "stringprep" module. This only affects domain names containing characters that were not previously registered or had their Unicode attributes such as case-folding behavior updated since Unicode 3.2.0.
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.
Analysis
by VulDB Data Team • 08/18/2026
The stringprep module, which is a core component for processing internationalized domain names and other text strings according to RFC 3454, contained a critical implementation flaw regarding the handling of specific character properties. The vulnerability stems from the module's reliance on the latest Unicode codepoint attributes available in the Python environment rather than strictly adhering to the static definitions provided by Unicode version 3.2.0 as mandated by the IDNA 2003 specification. RFC 3454 explicitly requires that implementations use a fixed snapshot of Unicode data to ensure consistency and predictability across different systems and time periods. By dynamically pulling updated attributes, such as case-folding behaviors or normalization rules, from newer Unicode versions, the module introduces non-deterministic behavior when processing strings that contain characters whose properties have changed since 2003. This deviation violates the fundamental principle of IDNA 2003, which is designed to provide a stable framework for internationalized domain name resolution by freezing character mappings at a specific point in time.
The operational impact of this flaw manifests primarily as mismatches during the processing of domain names that include characters registered or modified after Unicode 3.2.0. Specifically, the in_table_b2() function within the stringprep module fails to correctly identify and process characters listed in tables B.2 and B.3 of RFC 3454 when their attributes have been updated in subsequent Unicode releases. Table B.2 contains mappings for case-folding, while table B.3 lists characters that must be mapped to a space character or ignored during normalization. When the module applies newer attribute data instead of the specified legacy behavior, it may incorrectly fold cases or fail to strip prohibited characters. This leads to inconsistencies where two systems processing the same domain name using IDNA 2003 codecs might produce different results depending on their underlying Unicode library versions. Such discrepancies can cause DNS resolution failures, authentication errors in protocols relying on stringprep for identity verification, and general interoperability issues between legacy-compliant software and modern environments with updated Unicode databases.
From a security perspective, this vulnerability aligns with CWE-20 Improper Input Validation because the system fails to correctly validate input against the expected standard due to incorrect reference data. It also relates to CWE-1348 Incorrect Implementation of Canonicalization Rules, as the stringprep module is responsible for canonicalizing strings according to a specific RFC definition but instead applies an evolving set of rules that diverge from the specification. In terms of MITRE ATT&CK, this flaw could potentially be leveraged in techniques related to Domain Fronting or evasion if attackers can exploit inconsistencies between different DNS resolvers or authentication services by crafting domain names with characters whose properties have changed post-Unicode 3.2.0. For instance, an attacker might attempt to register a domain that appears identical to another under IDNA 2003 rules on older systems but differs under newer interpretations, potentially facilitating phishing campaigns or bypassing access controls that rely on strict string matching based on the legacy standard.
Mitigation for this vulnerability requires ensuring that applications using the stringprep module and idna codec are updated to versions where the Unicode data is pinned to version 3.2.0 as required by RFC 3454, rather than dynamically loading newer attributes. Developers should verify their Python environment's configuration of the unicodedata module or use a dedicated library that explicitly supports IDNA 2003 with frozen character tables. Additionally, organizations relying on internationalized domain names for security-critical operations such as email authentication (SPF/DKIM) or web application access control should audit their DNS resolution pipelines to ensure consistent behavior across all nodes in the infrastructure. Upgrading to patched versions of Python and associated libraries that correct this implementation error is essential to restore compliance with IDNA 2003 standards and prevent potential exploitation through character property manipulation.