Certaines normes internet ne prennent en charge que les caractères ASCII, mais le monde utilise bien plus que l'alphabet latin. Il est donc nécessaire d'établir une correspondance Unicode vers ASCII pour les noms de domaine. Name Prep faisait partie de cette solution, défini dans la RFC 3491 en tant que profil de String Prep, et est un composant crucial d'Internationalizing Domain Names in Applications (IDNA), également connu sous le nom de "IDNA 2003". L'algorithme String Prep est défini dans la RFC 3454. IDNA 2003 a été obsolète par IDNA 2008 définie dans les RFC 5890, 5891, 5892 et 5893. Python prend en charge IDNA 2003 via le codec idna (str.encode('idna')) et IDNA 2008 est supporté par le paquet idna sur l'Index des paquets Python. L'implémentation de Python de String Prep est implémentée dans le module stringprep de la bibliothèque standard.

En général, vous devriez utiliser le paquet idna (IDNA 2008) et non .encode("idna") (IDNA 2003), mais parfois vous avez besoin du comportement antérieur. String Prep définit l'étape "case folding" (pliage de casse) dans la section 3.2, permettant des comparaisons de chaînes insensibles à la casse, en mappant tous les caractères à travers les tables de mappage B.2 et B.3. B.2 est essentiellement str.lower(), convertissant tous les caractères en minuscules selon les règles Unicode et B.3 contient les exceptions.

L'appel str.lower() dans cette fonction est une vulnérabilité! Parce que str utilise quel que soit les données Unicode que l'interpréteur Python particulier est livré avec, vous pouvez déterminer quelle version de Unicode votre interpréteur Python utilise en accédant à unicodedata.unidata_version. Il existe également une base de données de données Unicode 3.2.0 disponible sur chaque version de Python (unicodedata.ucd_3_2_0) spécifiquement pour les algorithmes String Prep et IDNA. String Prep dépend de cette version spécifique de Unicode pour fonctionner de manière cohérente, les tables B.2 et B.3 dans la RFC 3454 sont essentiellement des règles de pliage de casse Unicode 3.2.0 encodées dans une table. Donc nous devons utiliser les règles de pliage de casse Unicode 3.2.0, pas les règles de pliage de casse Unicode plus récentes.

La correction a été de créer de nouvelles exceptions pour que str.lower() se comporte comme s'il utilisait Unicode 3.2.0 pour seulement certaines fonctions. Merci à Bitshift pour avoir signalé la vulnérabilité, Stan Ulbrych pour avoir co-développé la remédiation, et Marc-Andre Lemburg et Petr Viktorin pour avoir revu la remédiation. Voir CVE-2026-17084 pour plus de détails.

Entités clés : Entreprises : Python Software Foundation, Alpha-Omega | Personnes : Seth Larson, Bitshift, Stan Ulbrych, Marc-Andre Lemburg, Petr Viktorin