The vulnerability lies in the model loading mechanism for PII privacy-filters in OpenMed. The core of the issue is the use of trust_remote_code=True when loading Hugging Face models, which allows for remote code execution if a malicious model is loaded. The analysis of the patch commit 98724f65df98d7518b9006e6356740aa36c2f224 reveals three key functions that contributed to the vulnerability.
-
openmed.core.pii._looks_like_privacy_filter_identifier: This function used a weak substring match to identify privacy-filter models. An attacker could exploit this by creating a model with "privacy-filter" in its name (e.g., attacker/foo-privacy-filter-bar) to have it processed by the vulnerable loading path.
-
openmed.core.backends.create_privacy_filter_pipeline: This function, which is called when a privacy-filter model is identified, was instantiating PrivacyFilterTorchPipeline without explicitly setting trust_remote_code=False. This caused it to use the default value, which was True.
-
openmed.torch.privacy_filter.PrivacyFilterTorchPipeline.__init__: This is the function that ultimately loads the model. Its constructor had trust_remote_code defaulted to True, which is the direct cause of the remote code execution. The patch changes this default to False and adds a validation check to ensure that trust_remote_code=True is only ever used for models on a pre-approved allowlist.
An exploit would involve an unauthenticated attacker making a request to an endpoint like /pii/extract or /pii/deidentify and providing a model_name that points to a malicious Hugging Face repository. The overly permissive _looks_like_privacy_filter_identifier function would incorrectly classify the model, leading to the create_privacy_filter_pipeline function being called, which in turn would instantiate PrivacyFilterTorchPipeline with trust_remote_code=True, resulting in the execution of the attacker's code.