SECURITY Signal 424
Python fixes str.lower() mismatch in IDNA 2003 StringPrep that produced non-compliant domain encodings
↗
Python's StringPrep implementation used str.lower(), which relies on the interpreter's current Unicode version rather than the Unicode 3.2.0 data the IDNA 2003 specification requires, causing inconsistent domain name encodings.
The mismatch meant the same input string could encode to different IDNA values depending on the Python version's bundled Unicode data, breaking the guarantee of consistent domain name handling and creating a spoofing surface. The fix patches the case-folding step so it conforms to Unicode 3.2.0 regardless of the interpreter's Unicode version.
Written by elseif from the cluster below · every claim links back to a sourceThe three things worth knowing
StringPrep's case-folding step called str.lower(), which uses the Python interpreter's bundled Unicode version instead of the Unicode 3.2.0 data the specification mandates.
The discrepancy produced different IDNA 2003 encodings for the same input, such as 'ᎠᎠ' encoding to 'xn--58da' per spec but 'xn--kz9aa' under newer Unicode case-folding.
The remediation adds per-codepoint exceptions so str.lower() behaves as Unicode 3.2.0 within the StringPrep function; see CVE-2026-17084.
THE CLUSTER