CVE-2026-4372: Modelo de ameaça, causa raiz e defesa

Análise defensiva de uma vulnerabilidade crítica de execução remota de código (RCE) no transformers do Hugging Face.

---

Conteúdo

1. Vulnerabilidade em resumo
2. Confirme primeiro nas fontes primárias
3. Modelo de ameaça
4. Causa raiz
5. Defesa
6. Detecção

---

1. Vulnerabilidade em resumo

Campo	Valor
Identificador	CVE-2026-4372 / GHSA-29pf-2h5f-8g72
Componente	Hugging Face transformers
Classe	Execução remota de código (CWE-94, injeção de código)
Ponto de entrada	AutoModelForCausalLM.from_pretrained(), quando um modelo é carregado
Mecanismo	Uma configuração de atenção no config.json do modelo (attn_implementation / _attn_implementation_internal) faz com que a biblioteca baixe e execute código do atacante
Propriedade-chave	Contorna trust_remote_code=False, a configuração em que os usuários confiam para impedir exatamente isso
Corrigido em	transformers 5.3.0

Um usuário que deliberadamente deixou trust_remote_code=False para se manter seguro ainda estava exposto.

---

2. Confirme primeiro nas fontes primárias ⚠️

Verifique os detalhes abaixo nas fontes oficiais antes de tratá-los como definitivos:

• GHSA-29pf-2h5f-8g72 (aviso do GitHub): versões afetadas e resumo.
• Entrada do NVD para CVE-2026-4372: pontuação de gravidade e tipo de fraqueza.
• O commit de correção vinculado no aviso: mostra exatamente qual caminho de código foi fechado.

Há duas descrições de gatilho em circulação:

1. Um campo de atenção no config.json (_attn_implementation_internal).
2. O pacote kernels, frequentemente instalado por meio de transformers[all].

Muito provavelmente são o mesmo caminho: o campo de atenção nomeia um repositório do Hub, e o pacote kernels baixa e executa código a partir dele. Trate os nomes de campos aqui como provisórios até que o commit de correção os confirme.

---

3. Modelo de ameaça

3.1 Como um modelo é carregado

[ Model repo on the Hub ]       untrusted source
        │  config.json, tokenizer, weights, (code)
        ▼
[ Download to local cache ]
        ▼
[ Read config.json ]            settings become a config object
        ▼
[ Pick model class + attention type ]
        ▼
[ Build model, load weights ]
        ▼
[ Model runs in the user's process, with the user's permissions ]

3.2 Limites de confiança

#	Limite	Proteção que deveria aplicar-se
TB-1	Hub → disco local	Repositórios confiáveis, fixação a um commit específico
TB-2	Ficheiro de configuração → objeto de configuração	Permitir apenas valores conhecidos e seguros
TB-3	Objeto de configuração → código em execução	trust_remote_code
TB-4	Modelo → sistema operativo	Sandbox, privilégio mínimo

O bug é uma falha no TB-3: um valor do ficheiro de configuração chegou à execução de código sem passar pela verificação trust_remote_code.

3.3 Como uma vítima obtém o modelo de um atacante

• Nome de repositório semelhante, por exemplo, uma cópia próxima do nome de um modelo popular.
• Editor malicioso ou comprometido publica uma versão envenenada.
• Um tutorial, notebook ou dependência aponta para um repositório malicioso.
• Versão não fixada: um repositório que era seguro ontem serve hoje um ficheiro malicioso.

Em todos os casos, a vítima apenas executa a chamada normal, AutoModelForCausalLM.from_pretrained("<repo-id>").

---

4. Causa raiz

4.1 A proteção estava no caminho errado

trust_remote_code protege uma forma de executar código do repositório: ficheiros personalizados modeling_*.py. A definição de atenção era uma segunda forma que nunca passava por essa proteção.

     untrusted config.json attention setting
                    │
                    ▼
        "pick attention type" logic
                    │                  never checks:
                    ✗ ─────────────▶   trust_remote_code
                    ▼
     download + run code from the Hub (via `kernels`)

4.2 Fatores contribuintes

1. Duas rotas para a mesma ação perigosa, apenas uma delas protegida.
2. Uma configuração que selecionava código foi tratada como dado simples, com o nível de confiança de um número.
3. Um campo "interno" (prefixo _) ainda podia ser definido a partir de um ficheiro não confiável.
4. Um pacote opcional (kernels) ativava silenciosamente o ataque quando instalado, por exemplo via transformers[all].

4.3 Lição

Proteja a ação perigosa, não apenas uma rota para ela. Todos os caminhos que podem levar a "executar código" devem passar pela mesma verificação.

---

5. Defesa

A defesa é um único script autónomo, defence/safe_load.py. A sua função safe_from_pretrained() substitui from_pretrained() e executa quatro verificações antes de qualquer modelo ser carregado. Se uma falhar, lança UnsafeModelLoad e nada é carregado.

#	Verificação	O que faz
1	Versão	Recusa se transformers for anterior a 5.3.0. Esta é a correção real.
2	Kernels	Numa versão antiga, recusa se o pacote kernels estiver instalado, uma vez que o ataque precisa dele.
3	Config	Lê os ficheiros de configuração do modelo e recusa se contiverem uma definição de risco (ver abaixo). Os modelos do Hub são verificados e carregados no mesmo commit.
4	Código remoto	Define sempre trust_remote_code=False. Apenas boa prática: esta CVE contorna-o.

Uma versão antiga é recusada na verificação 1. As verificações 2 e 3 só são executadas numa versão antiga se a opção exclusiva de laboratório allow_vulnerable_env=True estiver definida.

O que a verificação 3 bloqueia:

• Uma definição de atenção (attn_implementation, _attn_implementation, _attn_implementation_internal) que não seja incorporada. Apenas eager, sdpa, flash_attention_2, flash_attention_3 e flex_attention são permitidas, pelo que um valor como attacker-org/evil-kernel é bloqueado, mesmo dentro de uma sub-configuração aninhada.
• Os campos _attn_implementation_internal, auto_map e custom_pipelines.
• Ficheiros de configuração que não possam ser lidos.
• Uma configuração passada diretamente com config=, uma vez que ignoraria a verificação.

Para modelos do Hub, apenas os ficheiros de configuração são descarregados, nunca pesos ou código. São descarregados num commit fixo, e o modelo é depois carregado a partir desse mesmo commit, pelo que os ficheiros não podem ser trocados entre a verificação e o carregamento. Após rever os avisos, uma pessoa pode anular a verificação 3 com accept_findings=True.

Situação	O que impede o ataque
transformers 5.3.0 ou mais recente	Verificação 1
Versão antiga, kernels instalado	Verificação 2
Versão antiga, definição de risco na config	Verificação 3
Repositório alterado após a verificação	Verificação 3 (mesmo commit verificado e carregado)

Limitação: a verificação 3 apenas conhece as definições listadas acima, pelo que não consegue detetar um novo ataque. Atualizar para transformers>=5.3.0 é a única correção completa.

---

6. Deteção

O componente de deteção identifica configurações de modelos Hugging Face potencialmente inseguras e dependências vulneráveis associadas à CVE-2026-4372. Fornece dois mecanismos de deteção independentes: análise estática de configuração e análise de dependências.

Ao contrário do componente de Defesa, estas ferramentas reportam potenciais riscos de segurança sem carregar modelos ou executar código não confiável.

6.1 Deteção Estática de Configuração