Alguns padrões da internet apenas suportam caracteres ASCII, mas o mundo usa muito mais do que o alfabeto latino. Portanto, é necessário um mapeamento de Unicode para ASCII para uso em nomes de domínio. Name Prep foi parte dessa solução, definido em RFC 3491 como um perfil de String Prep, e é um componente crucial de Internationalizing Domain Names in Applications (IDNA), também conhecido como "IDNA 2003". O algoritmo String Prep é definido em RFC 3454. IDNA 2003 foi obsoleto por IDNA 2008 definido em RFC 5890, 5891, 5892 e 5893. Python suporta IDNA 2003 através do codec idna (str.encode('idna')) e IDNA 2008 é suportado pelo pacote idna no Índice de Pacotes Python. A implementação de Python de String Prep é implementada no módulo stringprep da biblioteca padrão.

Em geral, você deve estar usando o pacote idna (IDNA 2008) e não .encode("idna") (IDNA 2003), mas às vezes você realmente precisa do comportamento anterior. String Prep define o passo "case folding" (dobra de caso) na Seção 3.2, habilitando comparações de strings insensíveis a maiúsculas/minúsculas, mapeando todos os caracteres através das tabelas de mapeamento B.2 e B.3. B.2 é essencialmente str.lower(), convertendo todos os caracteres para minúsculas de acordo com as regras de Unicode e B.3 contém as exceções.

A chamada str.lower() nesta função é uma vulnerabilidade! Porque str usa quaisquer dados Unicode que o interpretador Python específico fornece, você pode descobrir qual versão de Unicode seu interpretador Python usa acessando unicodedata.unidata_version. Também há um banco de dados de dados Unicode 3.2.0 disponível em todas as versões do Python (unicodedata.ucd_3_2_0) especificamente para os algoritmos String Prep e IDNA. String Prep depende dessa versão específica de Unicode para operar consistentemente, as tabelas B.2 e B.3 em RFC 3454 são essencialmente regras de dobra de caso Unicode 3.2.0 codificadas em uma tabela. Portanto, precisamos usar as regras de dobra de caso Unicode 3.2.0, não as regras de dobra de caso Unicode mais recentes.

A correção foi criar novas exceções para que str.lower() se comportasse como se estivesse usando Unicode 3.2.0 para apenas certas funções. Agradecimento a Bitshift por relatar a vulnerabilidade, Stan Ulbrych por co-desenvolver a remediação, e Marc-Andre Lemburg e Petr Viktorin por revisar a remediação. Veja CVE-2026-17084 para mais detalhes.

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