Os endpoints da API REST POST /pii/extract e POST /pii/deidentify aceitam um valor model_name do corpo da requisição. Em versões vulneráveis, o dispatcher do filtro de privacidade usava correspondência ampla por substring nesse valor controlado pelo atacante. Um nome de modelo como attacker/foo-privacy-filter-bar podia, portanto, ser roteado para o backend do filtro de privacidade.

Em implantações sem MLX/Torch, esse backend carregava artefatos de modelo Hugging Face por meio do Transformers com trust_remote_code=True. Se o repositório de modelos controlado pelo atacante contivesse código Transformers personalizado referenciado por meio de auto_map em config.json ou tokenizer_config.json, o Transformers importava e executava esse código Python durante o carregamento do modelo ou do tokenizador.

O código importado era executado com os privilégios do processo do serviço OpenMed.

Impacto

Um atacante remoto não autenticado que consiga acessar a API REST do OpenMed pode executar código Python arbitrário no servidor ao fornecer um identificador de modelo malicioso no estilo Hugging Face em model_name.

Dependendo da implantação do serviço, isso pode permitir:

• Ler ou modificar arquivos acessíveis ao processo do OpenMed.
• Acessar variáveis de ambiente e segredos da aplicação.
• Chamar serviços internos acessíveis a partir do host do OpenMed.
• Interromper ou substituir o comportamento da aplicação.

Endpoints Afetados

O problema é acessível por meio de ambos os endpoints PII, pois ambos aceitam model_name e usam o mesmo caminho de extração/carregamento de modelos PII:

Detalhe Técnico

O fluxo de controle vulnerável apresenta duas falhas de limite de confiança:

1. A API confiava em um model_name fornecido pelo usuário ao selecionar o backend do filtro de privacidade.
2. O backend selecionado confiava em código de repositório de modelos remoto ao carregar artefatos do Transformers com trust_remote_code=True.

O dispatcher tratava qualquer identificador de modelo que contivesse privacy-filter como parte da família do filtro de privacidade. Isso permitia que identificadores controlados pelo atacante, por exemplo attacker/foo-privacy-filter-bar, alcançassem um caminho de código destinado aos modelos confiáveis de Filtro de Privacidade de primeira parte.

Uma vez roteado para lá, o Transformers podia carregar código personalizado controlado pelo atacante por meio de auto_map. Essa importação ocorre durante o carregamento do modelo/tokenizador, antes que qualquer inferência útil precise ser bem-sucedida. Uma prova de payload pode, portanto, ser tão pequena quanto:

Prova de Conceito

poc_exploit.py cria um diretório de modelo local inofensivo no estilo Hugging Face cujo nome contém privacy-filter. Os módulos Transformers personalizados gerados gravam um arquivo de marcação ao serem importados. O script então envia uma requisição a uma instância de teste da API do OpenMed usando esse diretório como model_name.

O comportamento esperado nas versões vulneráveis do OpenMed é:

1. A API aceita o model_name controlado pelo atacante.
2. O roteamento por substring o envia para o backend do filtro de privacidade.
3. O Transformers importa o módulo personalizado gerado porque trust_remote_code=True.
4. O arquivo de marcação é criado, provando a execução de código no processo do serviço OpenMed.
5. A requisição pode falhar depois disso porque o modelo de brinquedo não é um modelo real de Filtro de Privacidade; o marcador em tempo de importação é a prova relevante.

Execute apenas contra uma instância de teste local:

Se o serviço OpenMed for executado em algum lugar que não possa acessar o diretório local gerado, publique um modelo de teste equivalente em um repositório Hugging Face controlado e passe esse identificador explicitamente:

Remediação

Atualize para o OpenMed 1.5.2 ou posterior.

O OpenMed 1.5.2 separa o roteamento da confiança:

• Nomes de repositório arbitrários que contenham privacy-filter não são mais roteados pelo caminho confiável do filtro de privacidade.
• PrivacyFilterTorchPipeline define trust_remote_code como False por padrão.
• Apenas repositórios explícitos de Filtro de Privacidade de primeira parte são incluídos na allowlist para carregamento confiável de código remoto.
• Operadores que precisam de ajustes finos privados e controlados podem adicioná-los à allowlist com OPENMED_TRUSTED_REMOTE_CODE_MODELS.

Se a atualização imediata não for possível:

• Não exponha a API REST vulnerável a clientes não confiáveis.
• Não passe valores de model_name controlados pelo usuário para o Transformers com trust_remote_code=True.
• Substitua o roteamento de modelos baseado em substring por identificadores exatos de modelos confiáveis.
• Pré-carregue artefatos de modelos locais aprovados em produção e desabilite downloads arbitrários de modelos.

Cronograma de Divulgação

Crédito

Descoberta e reportada por Sai Teja Erukude, coordenada por meio da VulnCheck.

Referências

• Registro CVE: https://www.cve.org/CVERecord?id=CVE-2026-47117
• NVD: https://nvd.nist.gov/vuln/detail/CVE-2026-47117
• Aviso da VulnCheck: https://www.vulncheck.com/advisories/openmed-remote-code-execution-via-pii-model-loading
• Notas de versão do OpenMed 1.5.2: https://github.com/maziyarpanahi/openmed/releases/tag/v1.5.2
• Projeto OpenMed: https://github.com/maziyarpanahi/openmed