saiteja-erukude/cve-2026-47117-openmed-rceOpenMed < 1.5.2 RCE ohne Authentifizierung über das Laden des PII-Datenschutzfilter-Modells und trust_remote_code=True
Schweregrad: Kritisch, CVSS 4.0 9.3, CVSS 3.1 9.8 (vergeben von VulnCheck, der CNA)
Vektor (v4.0): CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N
Vektor (v3.1): CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
Betroffen: OpenMed < 1.5.2
Behoben in: 1.5.2
CWE: CWE-94 (Improper Control of Generation of Code, Code Injection)
Entdeckt und gemeldet von: Sai Teja Erukude
Veröffentlicht: 2. Juni 2026
OpenMed vor 1.5.2 enthält eine nicht authentifizierte Remote-Code-Ausführungsschwachstelle im Ladepfad des PII-Privacy-Filter-Modells.
Die REST-API-Endpunkte POST /pii/extract und POST /pii/deidentify akzeptieren einen model_name-Wert aus dem Request-Body. In anfälligen Versionen verwendete der Privacy-Filter-Dispatcher eine breite Teilstring-Übereinstimmung auf diesem vom Angreifer kontrollierten Wert. Ein Modellname wie attacker/foo-privacy-filter-bar konnte daher in das Privacy-Filter-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, auf den über auto_map in config.json oder tokenizer_config.json verwiesen wurde, importierte und führte Transformers diesen Python-Code während des Ladens des Modells oder Tokenizers aus.
Der importierte Code wurde mit den Rechten des OpenMed-Dienstprozesses ausgeführt.
Ein nicht authentifizierter Remote-Angreifer, der die OpenMed-REST-API erreichen kann, kann beliebigen Python-Code auf dem Server ausführen, indem er eine bösartige Modellkennung im Hugging-Face-Stil in model_name angibt.
Je nach Bereitstellung des Dienstes kann dies Folgendes ermöglichen:
Das Problem ist über beide PII-Endpunkte erreichbar, da beide model_name akzeptieren und denselben PII-Extraktions-/Modellladepfad verwenden:
POST /pii/extract
Content-Type: application/json
{
"text": "John Doe called 555-1212",
"model_name": "attacker/foo-privacy-filter-bar",
"confidence_threshold": 0.0
}
POST /pii/deidentify
Content-Type: application/json
{
"text": "John Doe called 555-1212",
"model_name": "attacker/foo-privacy-filter-bar",
"confidence_threshold": 0.0
}
Der verwundbare Kontrollfluss weist zwei Vertrauensgrenzen-Verletzungen auf:
model_name bei der Auswahl des Privacy-Filter-Backends.trust_remote_code=True geladen wurden.Der Dispatcher behandelte jede Modellkennung, die privacy-filter enthielt, als Teil der Privacy-Filter-Familie. Dies ermöglichte vom Angreifer kontrollierte Kennungen, zum Beispiel attacker/foo-privacy-filter-bar, einen Codepfad zu erreichen, der für vertrauenswürdige First-Party-Privacy-Filter-Modelle vorgesehen war.
Sobald dorthin geleitet, konnte Transformers vom Angreifer kontrollierten benutzerdefinierten Code über auto_map laden. Dieser Import erfolgt während des Ladens von Modell/Tokenizer, bevor eine nützliche Inferenz erfolgreich sein muss. Eine Proof-Nutzlast kann daher so klein sein wie:
from pathlib import Path
Path("marker.txt").write_text(
"custom Transformers code executed via trust_remote_code\n",
encoding="utf-8",
)
poc_exploit.py erstellt ein harmloses lokales Modellverzeichnis im Hugging-Face-Stil, dessen Name privacy-filter enthält. Die generierten benutzerdefinierten Transformers-Module schreiben beim Import eine Markerdatei. Das Skript sendet anschließend eine Anfrage an eine Testinstanz der OpenMed-API mit diesem Verzeichnis als model_name.
Das erwartete Verhalten bei anfälligen OpenMed-Versionen ist:
model_name.trust_remote_code=True gesetzt ist.Nur gegen eine lokale Testinstanz ausführen:
pip install -r requirements.txt
python poc_exploit.py --target http://127.0.0.1:8000 --endpoint /pii/extract
Wenn der OpenMed-Dienst an einem Ort läuft, der nicht auf das generierte lokale Verzeichnis zugreifen kann, veröffentlichen Sie ein äquivalentes Testmodell in einem kontrollierten Hugging Face-Repository und übergeben Sie diesen Bezeichner explizit:
python poc_exploit.py \
--target http://127.0.0.1:8000 \
--model-name your-org/foo-privacy-filter-bar \
--marker marker.txt
Aktualisieren Sie auf OpenMed 1.5.2 oder höher.
OpenMed 1.5.2 trennt Routing von Vertrauen:
privacy-filter enthalten, werden nicht mehr über den vertrauenswürdigen privacy-filter-Pfad geleitet.PrivacyFilterTorchPipeline setzt trust_remote_code standardmäßig auf False.OPENMED_TRUSTED_REMOTE_CODE_MODELS auf die Allowlist setzen.Falls ein sofortiges Upgrade nicht möglich ist:
model_name-Werte an Transformers mit trust_remote_code=True.| Datum | Ereignis |
|---|---|
| 18. Mai 2026 | Schwachstelle bei VulnCheck eingereicht |
| 20. Mai 2026 | VulnCheck initiierte die koordinierte Offenlegungskontaktaufnahme |
| 22. Mai 2026 | CVE-2026-47117 vorläufig zugewiesen |
| 1. Juni 2026 | OpenMed 1.5.2-Fix überprüft und bestätigt |
| 2. Juni 2026 | CVE-2026-47117 veröffentlicht |
Entdeckt und gemeldet von Sai Teja Erukude.
Die Offenlegung wurde über VulnCheck koordiniert.