Gli endpoint dell'API REST POST /pii/extract e POST /pii/deidentify accettano un valore model_name dal corpo della richiesta. Nelle versioni vulnerabili, il dispatcher del privacy-filter utilizzava un ampio matching per sottostringa su questo valore controllato dall'attaccante. Un nome di modello come attacker/foo-privacy-filter-bar poteva quindi essere instradato verso il backend del privacy-filter.

Nelle distribuzioni non MLX/Torch, quel backend caricava gli artefatti dei modelli Hugging Face tramite Transformers con trust_remote_code=True. Se il repository di modelli controllato dall'attaccante conteneva codice Transformers personalizzato referenziato tramite auto_map in config.json o tokenizer_config.json, Transformers importava ed eseguiva quel codice Python durante il caricamento del modello o del tokenizer.

Il codice importato veniva eseguito con i privilegi del processo del servizio OpenMed.

Impatto

Un attaccante remoto non autenticato in grado di raggiungere l'API REST di OpenMed può eseguire codice Python arbitrario sul server fornendo un identificatore di modello in stile Hugging Face dannoso in model_name.

A seconda della distribuzione del servizio, ciò può consentire:

• La lettura o la modifica dei file accessibili al processo OpenMed.
• L'accesso alle variabili d'ambiente e ai segreti dell'applicazione.
• La chiamata di servizi interni raggiungibili dall'host OpenMed.
• L'alterazione o la sostituzione del comportamento dell'applicazione.

Endpoint Interessati

Il problema è raggiungibile tramite entrambi gli endpoint PII perché entrambi accettano model_name e utilizzano lo stesso percorso di caricamento del modello/estrazione PII:

Dettaglio Tecnico

Il flusso di controllo vulnerabile presenta due fallimenti dei confini di fiducia:

1. L'API si fidava di un model_name fornito dall'utente nella selezione del backend del privacy-filter.
2. Il backend selezionato si fidava del codice del repository di modelli remoto caricando gli artefatti Transformers con trust_remote_code=True.

Il dispatcher trattava qualsiasi identificatore di modello contenente privacy-filter come parte della famiglia privacy-filter. Ciò consentiva a identificatori controllati dall'attaccante, ad esempio attacker/foo-privacy-filter-bar, di raggiungere un percorso di codice destinato a modelli Privacy Filter di prima parte fidati.

Una volta instradato lì, Transformers poteva caricare codice personalizzato controllato dall'attaccante tramite auto_map. Questa importazione avviene durante il caricamento del modello/tokenizer, prima che qualsiasi inferenza utile debba riuscire. Un payload dimostrativo può quindi essere minimo come:

Proof of Concept

poc_exploit.py crea una directory di modelli locale innocua in stile Hugging Face il cui nome contiene privacy-filter. I moduli Transformers personalizzati generati scrivono un file marker quando vengono importati. Lo script invia quindi una richiesta a un'istanza di test dell'API OpenMed con quella directory come model_name.

Il comportamento atteso sulle versioni vulnerabili di OpenMed è:

1. L'API accetta il model_name controllato dall'attaccante.
2. L'instradamento per sottostringa lo invia al backend del privacy-filter.
3. Transformers importa il modulo personalizzato generato perché trust_remote_code=True.
4. Il file marker viene creato, dimostrando l'esecuzione del codice nel processo del servizio OpenMed.
5. La richiesta potrebbe fallire successivamente perché il modello giocattolo non è un vero modello Privacy Filter; il marker al momento dell'importazione è la prova rilevante.

Eseguire solo contro un'istanza di test locale:

Se il servizio OpenMed viene eseguito in un ambiente che non può accedere alla directory locale generata, pubblica un modello di test equivalente in un repository Hugging Face controllato e passa esplicitamente quell'identificatore:

Rimedio

Aggiornare a OpenMed 1.5.2 o successivo.

OpenMed 1.5.2 separa l'instradamento dalla fiducia:

• I nomi di repository arbitrari contenenti privacy-filter non vengono più instradati attraverso il percorso fidato del privacy-filter.
• PrivacyFilterTorchPipeline imposta trust_remote_code su False per impostazione predefinita.
• Solo i repository espliciti di prima parte Privacy Filter sono inseriti nella allowlist per il caricamento fidato di codice remoto.
• Gli operatori che necessitano di fine-tune privati controllati possono inserirli nella allowlist con OPENMED_TRUSTED_REMOTE_CODE_MODELS.

Se non è possibile un aggiornamento immediato:

• Non esporre l'API REST vulnerabile a client non fidati.
• Non passare valori model_name controllati dall'utente a Transformers con trust_remote_code=True.
• Sostituire l'instradamento dei modelli basato su sottostringhe con identificatori esatti fidati.
• Precaricare gli artefatti dei modelli locali approvati in produzione e disabilitare i download arbitrari di modelli.

Cronologia della Divulgazione

Crediti

Scoperta e segnalata da Sai Teja Erukude, coordinata tramite VulnCheck.

Riferimenti

• CVE Record: https://www.cve.org/CVERecord?id=CVE-2026-47117
• NVD: https://nvd.nist.gov/vuln/detail/CVE-2026-47117
• VulnCheck advisory: https://www.vulncheck.com/advisories/openmed-remote-code-execution-via-pii-model-loading
• OpenMed 1.5.2 release notes: https://github.com/maziyarpanahi/openmed/releases/tag/v1.5.2
• OpenMed project: https://github.com/maziyarpanahi/openmed