Algunos estándares de internet solo admiten caracteres ASCII, pero el mundo utiliza mucho más que el alfabeto latino. Por lo tanto, se requiere un mapeo de Unicode a ASCII para su uso en nombres de dominio. Name Prep fue parte de esa solución, definido en RFC 3491 como un perfil de String Prep, y es un componente crucial de Internationalizing Domain Names in Applications (IDNA), también conocido como "IDNA 2003". El algoritmo String Prep está definido en RFC 3454. IDNA 2003 ha sido obsoleto por IDNA 2008 definido en RFC 5890, 5891, 5892 y 5893. Python admite IDNA 2003 a través del codec idna (str.encode('idna')) y IDNA 2008 es soportado por el paquete idna en el Índice de Paquetes de Python. La implementación de Python de String Prep está implementada en el módulo stringprep de la biblioteca estándar.

En general, deberías estar usando el paquete idna (IDNA 2008) y no .encode("idna") (IDNA 2003), pero a veces necesitas el comportamiento anterior. String Prep define el paso "case folding" (doble pliegue de caso) en la Sección 3.2, permitiendo comparaciones insensibles a mayúsculas/minúsculas de cadenas, mapeando todos los caracteres a través de las tablas de mapeo B.2 y B.3. B.2 es esencialmente str.lower(), convirtiendo a minúsculas todos los caracteres según las reglas de Unicode y B.3 contiene las excepciones.

La llamada str.lower() en esta función es una vulnerabilidad. ¡Porque str utiliza cualquier datos Unicode que el intérprete de Python específico tenga incluidos, puedes averiguar qué versión de Unicode utiliza tu intérprete de Python accediendo a unicodedata.unidata_version. También hay una base de datos de datos Unicode 3.2.0 disponible en todas las versiones de Python (unicodedata.ucd_3_2_0) específicamente para los algoritmos String Prep e IDNA. String Prep depende de esta versión específica de Unicode para operar de manera consistente, las tablas B.2 y B.3 en RFC 3454 son esencialmente reglas de doble pliegue de caso Unicode 3.2.0 codificadas en una tabla. Por lo tanto, necesitamos usar las reglas de doble pliegue de caso Unicode 3.2.0, no las reglas de doble pliegue de caso Unicode más recientes.

La corrección fue crear nuevas excepciones para que str.lower() se comportara como si estuviera usando Unicode 3.2.0 para solo ciertas funciones. Gracias a Bitshift por informar la vulnerabilidad, Stan Ulbrych por co-desarrollar la remediación, y Marc-Andre Lemburg y Petr Viktorin por revisar la remediación. Vea CVE-2026-17084 para más detalles.

Entidades clave: Empresas: Python Software Foundation, Alpha-Omega | Personas: Seth Larson, Bitshift, Stan Ulbrych, Marc-Andre Lemburg, Petr Viktorin