GPU VulnDB

Database/AI/ML frameworks & serving

OpenMed: unauthenticated model_name routes to a trust_remote_code loader and executes attacker code

CVE-2026-47117AI/ML frameworks & servingcurated

Impact

The privacy-filter dispatcher matched the user-supplied model_name by substring, so a value like attacker/foo-privacy-filter-bar routes into a Hugging Face load with trust_remote_code=True. The attacker publishes a repo whose config.json or tokenizer_config.json declares an auto_map, and the custom Transformers code is imported and executed as the OpenMed service process - on the inference host, with whatever the service account holds and whatever GPUs the process has open. This is the standard remote-code-in-a-model-repo failure, reachable here without authentication. Public exploit code exists in the references, so treat exposed instances as already at risk.

Who can reach it

Anyone who can send a request to the OpenMed service with a chosen model_name. No authentication required.

What to do

Upgrade OpenMed to 1.5.2 and restart the service - a process restart on the serving host, no node drain. Until then, block or allowlist the model_name parameter at the ingress so only known-good repository names reach the dispatcher, and treat any instance that was network-reachable as potentially executed against.

References

Related entries

All AI/ML frameworks & serving entries

This entry is curated: imported from vendor advisories with machine assistance, not yet individually verified. Confirm against your vendor's advisory before acting, and report anything wrong.