Um ficheiro de configuração não deveria executar coisa alguma
Um programador de um fabricante europeu descarrega um modelo de um hub público, chama from_pretrained e vai almoçar. A biblioteca obtém os pesos, lê o ficheiro JSON que os descreve e inicializa. Nada nesta sequência se parece com um consentimento para executar o código de um desconhecido, e o programador já definiu trust_remote_code como False precisamente para que não seja.
Os investigadores de segurança da Pluto Security demonstraram que era. A falha está registada como CVE-2026-4372, tem uma pontuação base CVSS de 7,8 e está classificada em CWE-502, desserialização de dados não fidedignos. Transforma o descarregamento rotineiro de um modelo em execução arbitrária de Python na máquina que o descarrega, e a ação exigida ao utilizador não é mais do que a forma documentada de carregar um modelo.
Como um campo de metadados passou ao lado da flag
A flag protege ficheiros de código. O ataque chegou pelos metadados. O construtor da configuração continha um ciclo que pegava em todas as chaves e valores do JSON não fidedigno e os escrevia diretamente no objeto de configuração, sem lista de permissões e sem validação. Entre os campos que um atacante podia assim definir estava um chamado _attn_implementation_internal, um atributo interno privado que ninguém esperava que fosse alcançável a partir de um ficheiro descarregado.
Quando esse campo continha uma cadeia de caracteres com a forma de proprietário e repositório, o carregador de kernels tratou-a como um pacote a obter do hub e importou-o sem qualquer verificação de segurança. Qualquer código Python colocado no ficheiro de inicialização desse repositório era então executado. O mecanismo de consentimento em que os programadores confiam nunca chegou a ser consultado, porque estava delimitado ao código de modelação personalizado e isto não era código de modelação personalizado. Era um ficheiro de definições.
A correção chegou primeiro. O aviso demorou mais 81 dias
As datas são a história. O código vulnerável entrou na biblioteca a 29 de agosto de 2025 e seguiu em todas as releases durante cerca de seis meses. A falha foi comunicada através de um programa de bug bounty a 23 de fevereiro de 2026, um dos responsáveis pela manutenção abriu a correção a 2 de março e a versão 5.3.0 fechou-a a 4 de março. Foi uma resposta rápida e digna de crédito, dez dias entre a comunicação e a release corrigida.
Depois o registo público ficou em silêncio. A CVE-2026-4372 só foi publicada a 24 de maio de 2026, 81 dias depois de a correção já estar disponível numa release pública. Nesse intervalo, a correção foi descrita nas notas de release como um problema de segurança do pacote kernels, sem número de CVE, sem gravidade e sem qualquer menção a que travava uma execução remota de código. Qualquer operador cuja aplicação de correções é desencadeada por feeds de CVE e por avisos dos fornecedores, o que abrange a maioria dos operadores regulados na Europa, não teve sinal algum para dar prioridade a uma atualização que já estava disponível.
Depois o próprio hub foi invadido pela mesma classe de porta
A 16 de julho de 2026 a Hugging Face divulgou uma intrusão em parte da sua própria infraestrutura de produção. Um dataset malicioso abusou de dois caminhos de execução de código no processamento de datasets, um carregador de datasets com código remoto e uma injeção de template numa configuração de dataset, para correr num worker de processamento. A partir daí o intruso escalou para o acesso ao node, recolheu credenciais de cloud e de cluster e moveu-se lateralmente para vários clusters internos ao longo de um fim de semana. A análise forense reviu mais de 17.000 ações registadas.
A Hugging Face afirma não ter encontrado indícios de adulteração de modelos, datasets ou Spaces públicos, e verificou que a sua cadeia de fornecimento de software estava limpa. Trate o incidente como prova do caminho de escalada e não como razão para desconfiar do hub. Um ficheiro que descreve dados chegou a um worker, e o worker guardava credenciais. É esta a forma do risco, e é a mesma forma da falha de configuração descrita acima.
O que decidir antes do próximo modelo que descarregar
Três verificações, por esta ordem. Confirme que versão do transformers corre nas suas imagens de treino, nos seus notebooks e nos seus agentes de build, e atualize tudo o que esteja abaixo da 5.3.0. Determine se o pacote kernels está instalado a par dela, uma vez que foi isso que tornou o caminho explorável. Depois veja que credenciais residem nas máquinas que interpretam artefactos de modelos e de datasets, porque essas máquinas são habitualmente tratadas como meras condutas de dados e recebem acessos amplos em conformidade.
O dever de comunicação corre num relógio próprio, independentemente disso. Ao abrigo do artigo 23.º da NIS2, uma entidade abrangida deve à sua autoridade nacional um alerta precoce no prazo de 24 horas após tomar conhecimento de um incidente significativo, uma notificação mais completa no prazo de 72 horas e um relatório final no prazo de um mês. Em Portugal, a orientação equivalente é dada pelo CNCS. Nenhum destes prazos se suspende enquanto apura que versão da biblioteca estava a utilizar.
Leia a seguir: Um pedido podia sequestrar o seu site WordPress | Aplicar o patch ao SharePoint já não fecha a porta
