Which versions of OpenMed are affected by EUVD-2026-33942?

OpenMed versions prior to 1.5.2 are vulnerable to unauthenticated remote code execution allowing attackers to execute arbitrary code on affected systems; no public exploit identified at time of…. A patch is available.

How to fix or mitigate EUVD-2026-33942?

Within 24 hours: Identify all systems running OpenMed prior to version 1.5.2 and assess network exposure. Within 7 days: Upgrade all vulnerable installations to OpenMed 1.5.2 or later. Within 30 days: Verify patch deployment across all systems and review logs for indicators of exploitation or suspicious activity.

OpenMed EUVD-2026-33942

Q: What is the CVSS score of EUVD-2026-33942?

EUVD-2026-33942 has a CVSS 4.0 base score of 9.3 (Critical). CVSS vector: 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/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X. EPSS exploitation probability: 0.2%.

| CVE-2026-47117 CRITICAL

Code Injection (CWE-94)

2026-06-02 VulnCheck

GHSA-m3v4-v5gx-7wf5

RCE Code Injection Openmed

9.3

CVSS 4.0 · Vendor: VulnCheck

Severity by source

Vendor (VulnCheck) PRIMARY

9.3 CRITICAL

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/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X

Primary rating from Vendor (VulnCheck) · only source for this CVE.

CVSS VectorVendor: VulnCheck

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/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X

Attack Vector

Network

Attack Complexity

Low

Privileges Required

None

User Interaction

None

Scope

Lifecycle Timeline

Analysis Updated

Jun 02, 2026 - 16:28 vuln.today

v3 (cvss_changed)

Analysis Updated

Jun 02, 2026 - 16:28 vuln.today

v2 (cvss_changed)

Re-analysis Queued

Jun 02, 2026 - 16:22 vuln.today

cvss_changed

CVSS changed

Jun 02, 2026 - 16:22 NVD

9.8 (CRITICAL) 9.3 (CRITICAL)

Source Code Evidence Fetched

Jun 02, 2026 - 16:00 vuln.today

Analysis Generated

Jun 02, 2026 - 16:00 vuln.today

DescriptionCVE.org

OpenMed before 1.5.2 contains a remote code execution vulnerability in the PII privacy-filter model loading path. The privacy-filter dispatcher used broad substring matching on the user-supplied model_name parameter, allowing a value such as attacker/foo-privacy-filter-bar to route through a path that loads Hugging Face models with trust_remote_code=True. An unauthenticated attacker can supply a malicious model repository containing custom Transformers code via auto_map in config.json or tokenizer_config.json, which is imported and executed with the privileges of the OpenMed service process.

AnalysisAI

Remote code execution in OpenMed before 1.5.2 allows unauthenticated attackers to execute arbitrary Python code on the OpenMed service by abusing broad substring matching in the PII privacy-filter model dispatcher to load attacker-controlled Hugging Face repositories with trust_remote_code=True. The flaw, reported by VulnCheck and tracked as CWE-94 (Code Injection), carries a CVSS 4.0 score of 9.3 and a vendor-released patch is available; no public exploit identified at time of analysis.

Technical ContextAI

OpenMed is a medical/healthcare-oriented Python application from maintainer maziyarpanahi (CPE cpe:2.3:a:maziyarpanahi:openmed) that ships a Privacy Filter pipeline for stripping PII from text using Hugging Face Transformers models. The vulnerable dispatcher decided whether a requested model belonged to the trusted 'privacy-filter' family using a broad substring match on the user-supplied model_name, so any repo identifier containing the substring 'privacy-filter' (e.g. attacker/foo-privacy-filter-bar) was treated as first-party and routed through a code path that instantiated the model with trust_remote_code=True. Hugging Face's trust_remote_code mechanism honors the auto_map entries in a repository's config.json or tokenizer_config.json, dynamically importing arbitrary Python modules shipped in the repo - the canonical CWE-94 (Improper Control of Generation of Code) sink - and executing them inside the loading process.

RemediationAI

Upgrade to the vendor-released patch OpenMed 1.5.2 (https://github.com/maziyarpanahi/openmed/releases/tag/v1.5.2), which is the authoritative fix landed via PR https://github.com/maziyarpanahi/openmed/pull/59 and commit https://github.com/maziyarpanahi/openmed/commit/98724f65df98d7518b9006e6356740aa36c2f224; 1.5.2 replaces substring matching with an explicit allowlist of first-party repos (openai/privacy-filter, OpenMed/privacy-filter-multilingual, OpenMed/privacy-filter-nemotron), flips PrivacyFilterTorchPipeline's trust_remote_code default to False, and fails fast for untrusted IDs. If you cannot upgrade immediately, prevent untrusted model_name values from reaching the privacy-filter dispatcher - restrict the endpoint behind authentication or a request filter that only permits the three first-party repo IDs above, and audit any code that constructs PrivacyFilterTorchPipeline with trust_remote_code=True (the trade-off is that legitimate custom fine-tunes will stop loading until allowlisted, which on 1.5.2 can be re-enabled per-deployment via the OPENMED_TRUSTED_REMOTE_CODE_MODELS environment variable). Additionally, run the OpenMed process as an unprivileged user with no outbound write access to model caches or secrets so that a successful exploit has minimal blast radius.